[Goodie] async message queues (was RE: passing cmds up from the VM, was pending mac vm 3.2.4)

Rob Withers rwithers12 at mediaone.net
Wed Feb 20 07:23:37 UTC 2002


At 06:02 PM 2/19/2002, you wrote:

> > > Now what interesting things can you do if you want to pass
> > > information upwards and you have 6 integers to work with?
> >
> > What you can (and should :-) do is to define one of these six ints as a
> > flag saying "there are n message in the queue please call the
> > appropriate primitive to retrieve the contents" and buffer everything in
> > the VM. No need to abuse the event structure just to stick in something
> > that it wasn't designed to deal with ;-)
> >
>
>This sounds Very Cool.

Lex, if you want to use the existing EventSensor, we could just make a new 
event-type (4) for callback events.  Then again there may be a better way 
to go.  David told us about having async message queues, with which you 
stick in a message (from c-code) and it does some semaphore magic so that 
squeak would ultimately 'execute' the message.  Aside from the object 
memory issue, variants of this mechanism should handle your cases below, 
depending on how we manage the callbacks in the c-code.

I have attached two zip files.  The events code is 3.2 code from the Stable 
Squeak effort and is a prerequisite for the async queues.  The async queues 
come in several varieties, all having a SharedQueue, mainly differing in 
insertion protocol.  This includes normal #nextPut:, #asyncSendMessage:, 
and #asyncSendMessage:future:.   In the VM, we would need a couple of c 
level semaphore, to protect insertions and removals with a pair of 
registered DispatchQueues.  This way we can have multiple c threads 
interacting with them.  The c-code for inserting a message to a queue would 
signal an soft interrupt to the interpreter.


>Now an issue that seems to have been ducked, is, what if the event wants
>to wait for a response?  For example, you have hooked up Squeak to a GUI
>toolkit, and your list widget is requesting the list of items to display
>from Squeak.  What do you do?

Use a vm-specific future that takes the result from Squeak and puts it onto 
an outgoing queue to the VM.  The consumer of this queue is again activated 
in checkInterrupts(), which would unblock the calling thread with the 
response.   See the FutureDispatchQueue class for how it manages the future 
- it points to the response queue, but it could also hold a request id and 
respond with that id.

For actually exporting callbacks, we would register exported functions,  to 
a VM export table, which would include the receiver and message as well as 
a description of the argument types.  FFI already has this description, 
doesn't it?

I have no idea how, but I feel that we should allow for a thread safe 
interface to object memory functions, to be used by threaded plugins.  We 
probably don't want to make the core object memory functions threadsafe, 
for performance reasons.    With checkInterrupts() we could process a queue 
of threads for object memory access, within certain time-bounds.  I liked 
the other idea of just stuffing the calls in byte arrays, and let Squeak do 
the marshalling.   Surely we can have a pool of byte arrays for callback 
messaging or something.

Cheers,
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: events-3.2.zip
Type: application/octet-stream
Size: 8996 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020220/6a885332/events-3.2.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: async-dispatch-queues.1.zip
Type: application/octet-stream
Size: 7051 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020220/6a885332/async-dispatch-queues.1.obj


More information about the Squeak-dev mailing list