That is how it would be called if the callback was defined in the primitive.
We would parse the return method and do a message send with the values from
the callback.

Which threading model do you prefer?

1) Thread ends at callback, access results through sharedQueue
2) Thread continues at callback, in main thread through eventloop
3) Thread continues at callback in its own thread at specified priority.

Which api do you prefer?

A) Access callback values in a queue 
B) Suspend and continue processing at callback from invocation.
C) Specify callback method in primitive

Based on your response preferring a message send I would assume you would
prefer either 2C or 3C.

I could be completely wrong but it seems to me that 1A is the easiest to
build and the safest to use.

2B is confusing to use but safe.

2C is easy to understand and matches what people would expect and is safe in
terms of threading but might have performance problems.

3C is easy to understand and matches what people would expect but it
requires additional care because of threading issues (anything the return
method does will have to be properly protected).

Ron Teitelbaum

> From: Alejandro F. Reimondo
> Sent: Friday, September 01, 2006 10:30 AM
> 
> 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
> > > >
> > >
> >
> >
> >
> 
>