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