Re: Microsecond sleeps with select()

> I have been thinking some more about the s_lock() delay loop in
> connection with this.  We currently have
> 
> /*
>  * Each time we busy spin we select the next element of this array as the
>  * number of microseconds to wait. This accomplishes pseudo random back-off.
>  * Values are not critical but 10 milliseconds is a common platform
>  * granularity.
>  *
>  * Total time to cycle through all 20 entries might be about .07 sec,
>  * so the given value of S_MAX_BUSY results in timeout after ~70 sec.
>  */
> #define S_NSPINCYCLE    20
> #define S_MAX_BUSY    1000 * S_NSPINCYCLE
> 
> int    s_spincycle[S_NSPINCYCLE] =
> {    0, 0, 0, 0, 10000, 0, 0, 0, 10000, 0,
>     0, 10000, 0, 0, 10000, 0, 10000, 0, 10000, 10000
> };
> 
> Having read the select(2) man page more closely, I now realize that
> it is *defined* not to yield the processor when the requested delay
> is zero: it just checks the file ready status and returns immediately.

Actually, a kernel call is something.  On kernel call return, process
priorities are checked and the CPU may be yielded to a higher-priority
backend that perhaps just had its I/O completed.

I think the 0 and 10000 are correct.  They would be zero ticks and one
tick.  You think 5000 and 10000 would be better?  I can see that.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026