[Vm-dev] An event driven Squeak VM
eliot.miranda at gmail.com
Wed Nov 11 02:17:52 UTC 2009
On Tue, Nov 10, 2009 at 5:56 PM, John M McIntosh <
johnmci at 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.
> Er, all of the above, from early practice on slow machines it gave sluggish
> response to early forms of the browser plugin.
> 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())
> #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,
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.
> John M. McIntosh <johnmci at smalltalkconsulting.com> Twitter:
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev