[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Cocoa primitives

On Tuesday, December 17, 2002, at 02:07 PM, James McCartney wrote:

Some more explanation:

While the SC interpreter may be called from multiple threads, while you are in the interpreter it holds a lock that prevents any other thread from also being in the interpreter. So anytime you do something in a primitive that can block, that prevents any other thread from using the interpreter. So in order to avoid this your primitive should not call something that blocks but instead send a message to another thread to do what it needs. This is what SCVirtualMachine defer: is for. It adds an NSInvocation to a list of things to be done. In idle time this list of invocations gets performed.

but then to call a dialog, i'm still going to want to use NSThread detachNewThreadSelector:toTarget:withObject:, right ?

here's what i'm trying right now:

CocoaDialog(.sc) makes an SC instance, retained in the classvar, holding the returnSlot, okFunc, cancelFunc.

	the primitive creates an objective-c instance of SCDialog:

	dialog = [[SCDialog receiver: receiver returnSlot: returnSlot] retain];
	[dialog detachWithSelector: @selector(getPaths)];

the SCDialog detaches the thread, does the dialog, and when it returns, calls "receiver perform sc method 'ok' ". (can't find that function,
i used it before)

now here i need to make sure that i re-enter correctly. i need to call the interpreter, and to do that i need to obtain a lock

	// "receiver perform sc method 'ok' "

i think SCVirtualMachine could have a method:

-(void)object:(PyrObject*)object perform:(PyrSymbol*)selector

The Function-defer method in the SC language controls which C language thread that the interpreter executes in. Specifically it causes it to execute in the Cocoa UI thread. If you are in the SystemClock thread you cannot call Cocoa directly, thus you defer to execute in the Cocoa thread. In either case, you will be holding the language lock while in the interpreter preventing any other thread from running the interpreter. So if you are in the Cocoa thread holding the language lock while a dialog is up, then the SystemClock thread must wait until you release the language lock by exiting the interpreter.

On Tuesday, December 17, 2002, at 10:27 AM, crucial felix wrote:

does it ? i thought by being in { }.defer from the client side where it was called,
that it cleverly and easily avoided that.

--- james mccartney james@xxxxxxxxxxxxxx <http://www.audiosynth.com> SuperCollider - a real time synthesis programming language for the PowerMac.

sc-dev mailing list