re: mysql sleep timeouts

[matthew green <mrg%eterna23.net@localhost>]

John Nemeth writes:
>      I'm seeing a problem in MySQL Cluster where sleep timeouts
> are running too long.  I don't know if this problem also affects
> regular MySQL, but since they share a lot of code, it is very
> possible.
>
>      After doing a fair bit of digging, I found a function called,
> NdbSleep_MilliSleep().  The primary line in this function is,
> "select(0, nullptr, nullptr, nullptr, &t);".  t is a "struct
> timeval".  I'm guessing that select() timeout doesn't provide
> millisecond level granularity?  Somebody can confirm.  What would
> be a better option (hopefully reasonably portable)?

what's "too long"?  note that you can't get sleeps with higher
resolution than hz currently, ie, default of 10ms, so if you're
seeing 10ms instead of 1ms, the only current workaround is to
run with HZ=1000 kernels.

when we have better timers available, the above method should
work fine -- select() passes microsecond precision we'd only have
to look it up to the future timer system.

(alternatively, if you _need_ this level of precision now, the
only real way is to hard-spin until time passes.)


.mrg.