> >         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.  :)
> >
[...]
> 
> I am not clear by what you mean for #4.  Why is it an issue that they 
> return in the a different order than they were called?  One calls return 
> should not interfere with another's call.

Consider the call stack:

	1. foo() calls interpret() and waits for an answer
	2. interpret() runs some Smalltalk code, that calls a primitive...
	3. the primitive calls bar() via some GUI callback
	4. bar() invokes interpret() again...
	5. the call to foo() finishes (maybe it's in another Smalltalk thread)
before bar

With the re-enter-interpret() approach, you can't just return the value
immediately to foo(), because bar() is more recently on the call stack. 
You have to stash the value somewhere, and also the version of
interpret() in step 2 needs to notice that during the primitive
invocation, bar() also got finished up.



> The 're-enter' would be a MessageSend 
> enqueued into the incomingVMQueue, and the 'return' would be a well defined 
> structure, enqueued into the outgoingVMQueue.

While these queues make sense (well, certainly the incoming one does;
maybe the outgoing one isn't that useful), you also need to re-invoke
interpret() recursively if the C function is waiting for a return value.


Gee, this is all so much work for what seems so simple on the face of
it.

-Lex