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.
