> Lex, if you want to use the existing EventSensor, we could just make a new 
> event-type (4) for callback events.  Then again there may be a better way 
> to go.  David told us about having async message queues, with which you 
> stick in a message (from c-code) and it does some semaphore magic so that 
> squeak would ultimately 'execute' the message.  Aside from the object 
> memory issue, variants of this mechanism should handle your cases below, 
> depending on how we manage the callbacks in the c-code.

Notifying the VM is the easy part.  You could even just not have events
at all, but a single semaphore that some process is waiting on.  Using
an event queue is probably nice, though it does seem odd to me to
intermix "mouse moved" events in the same queue as "incoming method
call".  Some Smalltalk-level process is just going to pass these events
in separate directions I would think.

But again, it's a small part of the issue.  The reamining problems are:

	1. Finding the right handler for the particular callback (You talked a
little about this -- sounds good to me!).

	2. Providing a way to get any parameters into the image.  Probably the
data is stuffed into a buffer that can then be read by some primitive
(rememebering, though, to read from the *correct* buffer).  Also, there
is an issue of C -> Smalltalk translation of things like int's and
strings.

	3. Making it possible to re-enter interpret() .

	4. Adding a way to *return* from interpret().  A complexity is that
multiple callbacks could be executing simultaneously and then return in
the wrong order -- thus you need to be able to leave a return in limbo
while some other callback is still processing.  Also, we might want to
put in a dummy check that no one returns from the top-level interpret()
call.  :)

	5. Of course, leaving a way for the "return" from Smalltalk code to
pass some data back.  This involves a Smalltalk->C translation.  And
don't forget that this data might get stored in a side buffer, if the
return from Smalltalk is in limbo.


Overall, I guess none of these is a *huge* deal, but I can see why
Andreas would run into time trouble with it.  :)  It would really expand
the things Squeak can be used for, however, because now it can interact
with a broader class of existing code.  In fact, you could even write a
Squeak library, which is kinda neat IMHO.


-Lex