> It really isn't all that pretty, but tends to do everything you can
> easily do without overcoming Squeak's not being re-entrant.

Actually, it's not all that hard to support callbacks. Back, when I wrote
the FFI I considered supporting callbacks but the major reason against it
was not the complexity but time constraints (the project we were working on
really needed it). If you wanted to do callbacks all you need to keep in
mind that the only, the exclusive place where a regular (not interrupt)
callback can occur is during a primitive call (obviously - all other methods
only run bytecodes and send further messages). Because of this, the entire
internal interpreter state is perfectly externalized so that it is quite
doable do simply "call back" into interpret(). So what you'd have to do is
essentially:

- define a number of callback stubs (could be a fixed number) which
    - remember the stack pointer for later use (to get the arguments)
    - mark itself as the "top-most C frame" being used
    - signal the callback semaphore associated with the stub
    - mark the execution point by a setjmp()
    - call interpret()
    - (after return through longjmp()) restore the prior top-most C frame
    - returns to caller

- define the "return from callback" primitive so that it
    - horribly barfs if it's not the top-most callback
      (this would mean you try to return through another C stack frame)
    - simply leaves interpret() by a longjmp to the callback stub

This should work just nicely - a bit of trickery is certainly needed but not
very much. Then, on the Squeak side what you do is:

- provide a Squeak process for each callback which
    - requests a new callback stub
    - sits waiting on the callback semaphore
    - when it wakes up requests the stack pointer
    - unpacks the arguments from the stack (via a few FFI primitives)
    - runs the associate callback block
    - returns via return from callback primitive

That's about it. If you want to get fancy you can add some stuff in the
Squeak process that serializes the returns appropriately so that callbacks
invoked from different processes work appropriately. But really, supporting
callbacks isn't all THAT hard ;-)

Cheers,
  - Andreas