Re: [sc-dev] Cocoa primitives

[crucial felix <felix@xxxxxxxxxxxxxxxxxxx>]

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

> Some more explanation:
thanks.

> 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

    pthread_mutex_lock(&gLangMutex);
	// "receiver perform sc method 'ok' "
    pthread_mutex_unlock(&gLangMutex);


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.
> <ftp://www.audiosynth.com/pub/updates/SC2.2.16.sea.hqx>
>
> _______________________________________________
> sc-dev mailing list
> sc-dev@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
-felix