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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026