Re: [sc-dev] Cocoa primitives

[James McCartney <asynth@xxxxxx>]

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.

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>