I've been thinking a bit about that.  I agree it is important that we define
a standard way to handle the api. It seems to me that a call to a call back
would automatically suspend a separate process with a semaphore.  This would
be automatic to the framework.  How the system handles the callback could
include one of the following:

1) The system would then have to wait on some structure like a SharedQueue
for a response; this would allow polling in the main thread for developers
to "attach" too.  It simplifies the framework since the framework ends with
depositing information into a thread safe area.

2) We could allow the event loop to poll for callbacks and process them in
turn.  This would allow a developer to write code that handles the
invocation by writing the handling code directly after the invocation, and
would remove some of the threading implications of the framework.  This
approach seems contrary to the way we normally think of callbacks, which
sends a non-blocking call and requires the developer to write a separate
method that gets invoked by the external program.  (although it is kinda
cool being able to write a branch of code that gets invoked and goes off on
its own I think it would be confusing)

3) We could let the developer write a return method after the
<apicallback:..> which would be called with some set priority and have
access to the values sent in and returned.  This to me would allow for
higher priority callbacks but since the code runs in its own thread the
developer would need to understand all the threading implications.  But it
does allow the receiver to be explicitly defined. 

We could also combine features of the above to get something different.

Do you have other suggestions?

Ron Teitelbaum
(Note discussion should not be considered to be an acceptance of the task to
write the framework, volunteers are welcome)



> From: Alejandro F. Reimondo
> Sent: Friday, September 01, 2006 9:16 AM
> 
> 
> > See, it's only four steps. How hard could it possibly be? ;-)
> Fine!
> Now we are ready to add the point number 5.
> 
> 5.- it must be realized in 100% smalltalk.
> e.g. included in FFI services to be understood
>  by squeak users (with at least one example of use).
> 
> One point to be considered is that "functions" on smalltalk
>  side are full messages (including a receiver) and
>  not compiled methods, because each callback instance
>  must be managed by a particular receiver.
> 
> best,
> Ale.
> 
> 
> ----- Original Message -----
> From: "Andreas Raab" <andreas.raab at gmx.de>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, August 31, 2006 10:57 PM
> Subject: Re: FFI Callbacks
> 
> 
> > Ron Teitelbaum wrote:
> > > A quick question, if callbacks are supported by the VM, and a plug-in
> can be
> > > written to handle callbacks couldn't someone (notice I didn't say "I"
> or
> > > "WE" hoping maybe one of the VM gurus would consider it) combine those
> > > features to write a generalized callback framework that would be
> available
> > > to the image?  For example it would define the function name return
> value
> > > and parameters, just like FFI but maybe be called <apicallback: ...>.
> Then
> > > that callback could be invoked within a semaphore on a separate
> thread.
> >
> > Yes. That is basically what I meant when I said "you need to pop the
> > arguments from the C stack". What you have to do goes somewhat along the
> > lines of the following:
> > 1. Set up a pool of callback functions that are varargs based. This
> > avoids the need to generate callbacks stubs (which may be preferrable on
> > some platforms but it doesn't matter). These functions need to "put
> > away" the stack pointer for the image to use, signal an FFI semaphore
> > and callback into the interpreter.
> > 2. When the callback is picked up in the image, the image needs to call
> > a set of support functions to take the arguments correctly from the
> > stack. This would be based on some ffi spec.
> > 3. Once all the arguments are picked up, you run your callback code.
> > 4. To return, you need to call another set of support functions for
> > storing the return value and return from the callback.
> >
> > See, it's only four steps. How hard could it possibly be? ;-)
> >
> > Cheers,
> >    - Andreas
> >
>