Tim,

> If you're handling events in a thread that is non-synchronous with the
> main VM, you can't safely create objects. You might find the VM is in
> the middle of creating one itself.... BOOM!

Which is one of the reasons for my proposal ;-)

> One of the more serious problems likely to surface is with events that
> require immediate response from the application in order to function
> correctly. I have no idea if this is still a problem but I do recall
> that it was a serious hassle for VW on win3.1 some years ago.

Actually, this shouldn't be such a big problem. In a threaded
environment you can just suspend the thread until the result is
computed. In a non-threaded one you can either have the main interpreter
loop run in a thread (I considered this for various reasons many times
before - it's not that hard to do but it requires a bit of
synchronization work for the display update operations) or you can just
call the interpreter again. I looked into this issue when I did the FFI
stuff (for supporting callbacks) and it turns out that this is actually
a relatively safe thing to do. As long as you can make sure that system
calls only come from primitives (which is true with the one exception of
interrupt checks which may call ioProcessEvents) then the control flow
in Squeak stays in sync. E.g., the entire interpret() state _is_
externalized which means you can in fact call interpret() again and
continue "as if returning from the primitive that did the syscall".

I won't go into details here (which are rather subtle but I'm sure you
of all people know ;-) but once again, the simplicity of Squeak's VM is
a huge virtue. The only reason I didn't complete callbacks for the FFI
stuff were time constraints - they weren't necessary for the project we
were working on and I wanted to complete the 3D stuff _much_ more than
any C callbacks ;-)

Cheers,
  - Andreas