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