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.
But with Gleixner's proposed fix, I'd have to run a test program that
will take 70 years to run, if I want to detect the bug in the
resulting kernel. (Most people wouldn't like it if './configure' took
70 years to execute. I know 'configure' is slow, but reeeallly! :-)
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;
and then fall through to the existing behavior. Am I missing something?
It sounds pretty easy.
If you can't fix the kernel bug, my advice is to leave the behavior
alone. Please don't make things worse by introducing a new bug that
is harder for applications to work around than the existing bug.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
