We can model the callback as a simple full
 message (aMessageSend) to be performed
 when activated.
Any objects that responds to:
    #arguments(:)
    #perform (or #evaluate )
 can be used as a callback hook.
I think there is no reason to hook aCompiledMethod...
Ale.

----- Original Message ----- 
From: "Ron Teitelbaum" <Ron at USMedRec.com>
To: "'The general-purpose Squeak developers list'"
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, September 01, 2006 11:04 AM
Subject: RE: FFI Callbacks


> 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
> > >
> >
>
>
>