Markus Gaelli <gaelli at emergent.de> wrote:

> > Ned Konz wrote:
> > It's too bad, really; if you look at the Ruby bindings for Gtk, you'll
> > see that the callback code is very small.
> >
> How hard would it be to change the current VM-Implementation(s?) to make
> callback-services possible? Impossible? If Ruby can, why can't we?
> 

Most of the problem simply seems very fiddly.  There are a lot of
details.

Let's step through it and see what is needed.

When the C callback gets invoked, it will want to fire up some Smalltalk
code.  The simplest way given the current implementation would be to
trigger a semaphore, re-invoke interpret(), and wait for the image to
signal that it has finished processing the request.  If there is a
return value from the callback, then this needs to be handled somewhere.
 The only new primitive needed by this discription is some sort of
"return:" primitive, which is allowed to supply a return value.

The hardest part seems to be converting between C data and Smalltalk
data.  In particular, what do you do with opaque pointers?

Finally, there is a complication if multiple callbacks are active at
once and they return in the wrong order.  This can happen if the
callbacks are handled in different threads!  It suggests that each
callback might be given a code, and return: should supply that code as
an argument.  Then there are two new tweaks to the system:

	1. return: doesn't actually return unless the code matches the expected
code.

	2. Somehow, "wrong" return's need to happen eventually.  Perhaps if a
return: fails, the process trying to return should be put on a separate
queue somewhere.  Then, the return: primitive can resume all processes
on that queue before it actually returns from interpret().  Then, the
next time interpret() is fired, all of these processes will try to
"return" again.

One little detail is to decide what places a callback may legally spring
from.  For example, the processIO primitive would be a logical placess
that it's allowed, and maybe any non-small primitive may do it.  The
main issue is that all interpreter state must be saved before the
interpreter is re-entered, and it must be restored afterwards.

Once all of this is in place, the VM should be sufficient.  Then, there
"simply" remains the problem of translating Squeak data to C data and
vice versa.  I mean, it would be especially nice if you could supply the
callback as a block and have Squeak handle all the conversions for you
automatically.  But I don't know the details of how to do this.  In
particular, we need to handle pointers to opaque C structures.


-Lex