Callbacks, simplified.

Rob Gayvert rtg at rochester.rr.com
Thu Jun 8 20:57:18 UTC 2006


Andreas Raab wrote:
>  > 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?

Yes, that should do the trick. I tried doing something like this awhile 
back, but couldn't get it to work reliably. I suspect the problem was 
that the process oop might move during a callback, in which case trying 
to resume it would cause a crash. It sounds like your other changes to 
keep oops across primitives would solve this.

.. Rob


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