[plt-scheme] scheme_check_threads gives Bus error on OS X

At Sun, 06 Nov 2005 12:09:41 -0500, Jon Rafkind wrote:
> On a side note when I try to link with libmzscheme.a I get errors about 
> the library being out of date and I should run ranlib on libmzscheme.a. 

libmzscheme.a and libmzgc.a are for embedding, not extending. By
linking to these, you're loading a second instance of MzScheme into the
process, and I guess that's why you're seeing bus errors.

I recommend using mzc to compile and link your C code. It uses the
right flags and libraries for an extension.

> >With either implementation, beware that calling the Cocoa API from
> >other MzScheme threads probably won't work. MzScheme thread swapping is
> >implemented by copying and overwriting the C stack. This means that if
> >any other MzScheme thread calls into the Cocoa API, Cocoa may notice
> >that the stack isn't consistent with the active event loop.
> >
> >  
> >
> Hm, that is disheartening. I assume DrScheme uses the Aqua framework or 
> something? Im not really familiar with OS X's gui stuff so I dont know 
> the difference between Cocoa and Aqua but is Aqua the only framework 
> that MzScheme can use?

MrEd uses Carbon, because it started as a Mac OS Classic application,
but the threading issues are pretty much the same. (Aqua is the
look-and-feel implemented by Carbon and Cocoa.) Possibly, with Carbon
it's easier to lift out more event dispatching, so that stack issues
show up less frequently, but MrEd does (carefully!) service a few
Carbon callbacks.

The simplest general solution is to create a kind of GUI-server thread.
All calls from the GUI go to this thread, which dispatches to handlers
in other threads. Similarly, all calls to the GUI go through the server
thread. So, when the server thread is waiting for an event to be
handled by other threads, it also services calls to the GUI from other
threads.

(This strategy doesn't work so well with eventspaces, which is why
MrEd's implementation is so complex.)

Matthew