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