Ron,
I prefer the most natural (naïve) model as default.
If there is more that one practical use of callbacks,
 subclassification (of Callback class) can be used to
 define the policy.
I will not put any preference for security, because
 I think that objects must not protect themselves
 (an object that protect itself will break other objects)
best,
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 12:23 PM
Subject: RE: FFI Callbacks


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