bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xnanosleep range with 64 bit time_t


From: Frank v Waveren
Subject: Re: xnanosleep range with 64 bit time_t
Date: Sat, 2 Sep 2006 10:42:09 +0200
User-agent: Mutt/1.5.9i

On Wed, Aug 30, 2006 at 10:13:52PM -0700, Paul Eggert wrote:
> 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.
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
address@hidden                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]