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