On Wed, Aug 30, 2006 at 10:13:52PM -0700, Paul Eggert wrote: > Frank v Waveren <[EMAIL PROTECTED]> writes: > > > Thomas Gleixner has submitted a replacing patch that instead just > > limits the timespec passed to the maximum, so that would make this > > patch unnecessary for linux (at least for those with new kernels). > > Sorry, no, that's worse. > > With the current Linux behavior, I can detect the bug and work around > it at 'configure' time using AC_RUN_IFELSE. The same is true for a > change to the kernel that would return EOVERFLOW for long sleeps; this > behavior is worse, in my opinion, since it will cause more work in the > application to work around, but the bug is still easily detectable at > configure-time. Yes, at first I agreed with you on that, but he gave the fairly solid argument that it turned behaviour back to the (broken) way it was before ktime was introduced.
> How about if you just fix nanosleep so that it works in general? > Surely nanosleep can just have a little loop like this: > > unsigned int eons = t.tv_sec >> 31; > for (i = 0; i < eons; i++) > sleep for 2**31 seconds; > t.tv_sec &= 0x7FFFFFFF; Yeah, I was being lazy. There seems to be a little trouble with the sleep-as-long-as-we-can patch anyway, I'll see if this isn't too tricky to hack up and try submitting it. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8
signature.asc
Description: Digital signature
_______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
