On Thu, 24 Oct 2013, Eliot Miranda wrote:
Can we please stop confusing the conversation and concentrate on the VM's bogus idle behaviour. What we should eb concentrating on now is arranging that the VM can enter a fully quiescent idle state that it will exit when
- i/o is possible (which includes input events, there are a form of "i" in "i/o"
- a signal is delivered (except this could also be a variation of the above)
- the next delay is due to fire
- a callback has occurred
I think I'm right in thinking that nothing else can happen that justifies the VM leaving its idle state.
Note that in the VisualWorks VM it is the scheduler that enters the idle state whenever there is no runnable process, and hence the idle process is conspicuously absent. And a very nice solution that is too.
Andreas made the EventVM[1][2][3][4] based on the Interpreter. And something similar was done for CogDroid[5], which is a event-driven StackVM.
Levente
[1] http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003385.html [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003437.html [3] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-January/003684.html [4] http://code.google.com/p/squeak-android-vm/ [5] https://code.google.com/p/squeakvm-tablet/