>> do {
>> (void)gettimeofday((struct timeval *) &tv, (struct timezone *) NULL);
>> } while (tv.tv_sec == prev_tv.tv_sec && tv.tv_usec == prev_tv.tv_usec);
> Yes, that's the difference between precision and resolution.
Yes, but that doesn't strike me as very relevant.
> While gettimeofday yields a value with a microsecond precision, the
> resolution depends on the timecounter, and some timecounters only
> provide a resolution of HZ ticks per second (usually 10ms).
Does any of this vary with CPU count?
Even if so:
(1) IIRC, I saw code to artificially increment tv_usec, to cause
consecutive calls to return different values. I'm not sure where I saw
that, though; it may not be relevant here.
(2) Even if it changes only every 10ms, waiting for it to change 100
times should not take more than a little over a second.
(3) None of the above explains ktrace showing gettimeofday taking
multiple _seconds_ - nor two CALLs and only one RET. That last
actually looks odd enough I suspect something is corrupting the trace.
> and using a polling loop for uniquid is what I'd expect from php.
Whether or not it's good, bad, or just ugly, it looks to me as though
it's exposed a bug.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
