On Tue, Nov 10, 2009 at 5:56 PM, John M McIntosh
<johnmci@smalltalkconsulting.com> wrote:
On 2009-11-10, at 4:35 PM, Andreas Raab wrote:
John M McIntosh wrote:
Ok, well
So does that mean you are:
[ ] in favor,
[ ] against such a change,
[ ] don't care,
[ ] think it can't work at all?
I'm not clear about your reply you seem to be saying all of the above at some point or other.
However if you feel this will fix issues on the Windows platform then it's not a problem for the os-x and iphone version to
work with it. For the iPhone perhaps we flip the model to call interpret() for some set time on each pass thru the runloop.
Current we have
#define browserPluginReturnIfNeeded() if (plugInTimeToReturn()) {ReturnFromInterpret();}
#define browserPluginInitialiseIfNeeded()
plugInTimeToReturn on os-x is defined to check flags that are set if the VM is running as a sub-process of the browser
and the browser has terminated, thus we want to terminate the VM.
So I'm wondering what the check will be, how many times per second will it be executed, and will
interpret() run for a set number of milliseconds, a suggested amount, or a number of bytes codes?
Or if I read correctly we exit from interpret() when there are no processes to run, then go back in
when we think an external event happens, or a Delay terminates.
The latter. The ideal thing for the VM to do when it discovers it has no processes to run is to call select, poll et al, with a timeout determined from the pending delay. This the VM will wake up as soon as it has work to do, either because input is available or a delay has expired. This is more difficult on platforms like Windows where there is no common wait-for-input mechanism other than increasingly obsolete WaitNextEvent style interfaces (the problem being using an event-driven non-blocking socket interface, yuck).
With the threaded Squeak VM I'm working on one can go one better and have a number of image-level processes that block in the FFI and a number of worker threads in the VM that block on OS semaphores waiting for the VM to give them something to do.
Andreas, note that my threaded work already arranges to exit the interpreter/JIT combination wen a thread has nothing to do. We should coordinate changes so that we maintain compatibility.
Re callbacks, an approach like Alien's is a good one. I'm not quite at the stage with the threaded FFI work to be implementing callbacks, but it is on my list and the Alien approach is a general one.
--