Ian Piumarta <ian.piumarta at inria.fr> wrote:
> Just an observation...
> 
> > On unix currently the example code cheerfully gives
> > 
> > 824->20 84->19 32->40 19->10 16->1
> 
> These (certainly the first three) look like multiples of the
> process timeslice quantum.
> 
> If you give a non-zero timeout to select() -- regardless of its relation
> to the quantum and/or how much time your process has left in its current
> timeslice -- and there's at least one other runnable process, the kernel
> has every right to switch to another process.  How long you have to wait
> to get control back then depends much more on the scheduling algorithm
> (possibly whether you're running as root with a raised scheduling
> priority) and the load on the machine than it does on how many
> milliseconds you asked to sleep for in select().


I missed the beginning, but note that if there is actually an incoming
event that would wake up select(), and if there are no other running
processes on the system, select() may well get woken up before a full
time quantum elapses.  It depends on the little details of the
scheduling algorithm.  Does anyone know what typical Unices do about
this kind of thing?  On an idle system, is it still possible to
reschedule a process before a timeslice boundary comes up?

A way to test this would be to set up two Squeak images to echo a byte
back and forth to each other a socket.  How many echoes per second can
it achieve?  More than 100?



> 
> Without really thinking about it, I suspect the best way to minimise
> latency in Delays and the like would be something like this in
> ioRelinquishProcessor():
> 
>   if (timeToSleep < longSleepTime)
>     pollForIoSleepingFor(0);
>   else
>     pollForIoSleepingFor(timeToSleep);
> 

This should yield very precise sleeps.  However, it does mean that
Squeak isn't playing nicely with system.  Also, if the above guess about
early wakeups is correct, then this won't help something like a network
server.  Finally, for the user interface, 100 ticks per second is surely
enough, especially when you note that the X server will be operating
under the same constraints.

-Lex