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