John M McIntosh <johnmci at smalltalkconsulting.com> wrote:> 
> I changed my ioRelinquishProcessorForMicroseconds to do
> 	GiveUPControlToCPU();
>          if (nextWakeupTick != 0 && ioMSecs() >= nextWakeupTick)
>              interruptCheckCounter = 0;
> 
> 

Oh good grief.  Let me get this straight.  Squeak asks to suspend itself
for 10 milliseconds (or whatever), and then when it comes back, it
doesn't check for delays that have come to pass in that time?  Is that
right?

If that's true, then yes, change it!  Whenever Squeak comes back from
sleeping, check the IO and check to see if a Delay needs to be woken up.

This shouldn't be a time drain.  After all, the VM has just gone to
sleep -- there can't be anything so pressing that a couple of system
calls will be a problem.  Also, don't check the time -- on Unix, and
probably other platforms, if ioRelinquish returns early it's because
there really is something that has happened -- thus the sooner you get
back, the *more* likely you should check for events.


By the way, if you have access to high-precision timers, then maybe you
should fire up a timer right before going to sleep, and have it fire
just once to wake you back up?  Then you'll know exactly what to set the
timer for.



> >Somehow I thought the os-x scheduler snatchs control away for 1/60 
> >of a second, but that doesn't jive
> 
> Ah, thats because there is a lower limit for the 
> interruptCheckCounter counter (1000). So it just happens running 1000 
> *interesting* bytecodes interspersed with usleep() takes 16ms or so.

It's a big coincidence, though.  And on Linux, it seems to take 10 ms. 
Do you know how to adjust this parameter?  It would be neat to see what
happens if you half it or double it.



-Lex



PS -- a little detail that has bugged me for a while, is that the idle
process doesn't check what Delay is doing.  It would be nice if it
modified the amount of time to sleep depending on the time before the
next delay will trigger, instead of just saying "1 millisecond" all the
time.  Alternatively, the ioRelinquish primitive could check this --
doesn't the VM know when the next Delay is supposed to fire?