Callbacks, simplified.
Rob Gayvert
rtg at rochester.rr.com
Wed Jun 7 20:43:29 UTC 2006
tim Rowledge wrote:
>
> On 6-Jun-06, at 5:00 PM, Andreas Raab wrote:
>
>> tim Rowledge wrote:
>>
>>> How are you proposing to deal with the callback at the higher
>>> levels? Is the plugin going to be allowed to cons up a message and
>>> 'send' it? Or.....?
>>
>>
>> This should be up to the plugin. I can't think of a good interface
>> right now given that we don't have enough examples to look at and
>> learn from. Personally, I'm just signaling a semaphore before the
>> callback and have the image "pull up" the arguments via primitives.
>> This avoids the need to do too much at the primitive level.
>
>
> So would simply using the normal semaphore signalling be ok? We already
> have external semaphore capability so it would certainly be simple to
> provide! If we implemented callbacks by taking a block (or a
> MessageSend?), making a Process that will use it, make the process wait
> on a Semaphore and pass the semaphore index down to the plugin, then
> signalling the semaphore would run the block/whatever and presumably
> ask the plugin for relevant arguments. As long as it can be
> non-synchronous that should work for a lot of cases, surely?
>
Hi guys,
This is basically what I'm currently doing in wxSqueak. I have two
different flavors of callbacks, one for event loops and another for
other callbacks. The only real difference between these two is that the
non-event callbacks have to handle a variety of arguments. In both cases
the callbacks must appear to be handled synchronously from the viewpoint
of the (wx) calling routine. The only serious difficulty I've
encountered with this scheme is with nested callbacks. I have a number
of cases where a callback handler triggers another callback. The problem
is that when the second callback is handled, the process in which the
first primitive was called may resume prematurely, causing the first
primitive to get an incorrect return value.
The only way I found to reliably handle this scenario is to have the
first primitive pass in another semaphore and a pointer in which to
store the return value, and have the primitive signal the semphore when
it's done. It's a bit ugly, but it does work. It would be much better if
the processes involved could be controlled by the framework.
Do you have any thoughts on how this could be handled better?
.. Rob
More information about the Vm-dev
mailing list