John M McIntosh
johnmci at smalltalkconsulting.com
Wed Jul 18 19:27:37 UTC 2007
That is what the getNextWakeupTick() does, it returns the time the vm
has to wakeup to service the next delay since at that point all
(a) waiting on a semaphore
(b) waiting on a Delay to terminate in the future which is found via
On Jul 18, 2007, at 12:15 PM, tim Rowledge wrote:
> While the subject is in the air, perhaps it would be worth
> considering what the ideal situation would be.
> For example, I would suggest we might drop the idea of a suspend-
> for-a-fixed-time and have a suspend until next alarm. That would be
> called by the background process when nothing else wants time and
> would suspend the vm until the time specified by the timer queue;
> perhaps some emergency backstop value might be used in case some
> twerp gets us into a state with no timer active and no Process
> doing anything. That ought to remove the problem of looping on a
> tiny delay, though if certain OSs can't sleep for very short
> periods I have no idea how they can do much at that point.
> OSs that have suitable asynchronous or interrupt driven input stuff
> can trigger the return from the suspend at need. OSs that don't
> (the only one I know of is RISC OS right now and I'll almost
> certainly be retiring from maintaining that soon) can probably set
> some vm-internal polling.
> I'm sure it would require some changes in the image to make this
> work properly but so what. Older images can run on older vms.
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Shift to the left! Shift to the right! Pop up, push down, byte,
> byte, byte!
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev