[Openmcl-devel] Threads and lispbuilder-sdl and cocoa

[Gary Byers]

The short version is that yes, most things in Cocoa (anything that
interacts with the event system and most drawing, unless you're
very careful about the latter) need to be run on the initial thread.

The CCL:PROCESS that represents the initial thread is the value
of CCL::*INITIAL-PROCESS*; to force arbitrary code to run in that
process, you can do:

(process-interrupt ccl::*initial-process* (lambda () (arbitrary-code)))

That works (when the target process is the Cocoa event thread) by enqueueing
an application-defined event (whose event handler calls the lambda.)  That
generally works, but if the event thread is doing something compute-bound
(it generally shouldn't ...) or modal (I'm not sure about this), the
interrupt won't be processed until the next trip through the main event
loop.


On Sat, 24 Apr 2010, Elliott Slaughter wrote:

> Hi,
> Lispbuilder has some known problems running on CCL OS X. Recently a user
> pointed out that the failures seen in CCL can be duplicated in SBCL by
> starting lispbuilder in a new thread. Our guess is that cocoa doesn't like
> being called from any thread other than the initial thread. (Lispbuilder
> uses a portable wrapper around cocoa.) I'm wondering if there is any way to
> arrange to have our cocoa code run in the initial thread (preferably without
> having to rewrite the existing wrapper)?
> 
> Thanks.
> 
> --
> Elliott Slaughter
> 
> "Don't worry about what anybody else is going to do. The best way to predict
> the future is to invent it." - Alan Kay
> 
>