[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xnanosleep range with 64 bit time_t
From: |
Paul Eggert |
Subject: |
Re: xnanosleep range with 64 bit time_t |
Date: |
Wed, 30 Aug 2006 22:13:52 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Frank v Waveren <address@hidden> 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.