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().

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);

where longSleepTime could be the timeslice quantum, or (better still) the
time remaining in the current timeslice -- which provides for busy waiting
when the next wakeup tick is only a very short (< a timeslice quantum)
time away.  Unfortunately the first of these is hard to determine
portably, and the second almost impossible outside the kernel.

Ian