Callbacks, simplified.
Andreas Raab
andreas.raab at gmx.de
Thu Jun 8 18:03:12 UTC 2006
> Do you have any thoughts on how this could be handled better?
How about we just suspend the currently active process when we re-enter
the interpreter? As long as the callback is synchronous (it better be)
this should work just fine, right?
Cheers,
- Andreas
Rob Gayvert wrote:
> 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