[Top][All Lists]
[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
signature.asc
Description: Digital signature
- Re: xnanosleep range with 64 bit time_t,
Frank v Waveren <=