Re: xnanosleep range with 64 bit time_t

[Frank v Waveren]

On Sun, Aug 27, 2006 at 11:04:23PM -0700, Paul Eggert wrote:
> Frank v Waveren <address@hidden> writes:
> > I haven't checked how other operating systems handle this (do any
> > others even have 64 bit time_t's?)
> Yes, pretty much every operating system with 64-bit long has 64-bit
> time_t, which means most OSes these days (at least on some platform).
> So we can't install that patch as-is: it would break things on too
> many platforms.
After mailing the above, I went and had a look at a solaris machine.
Guess what?

0.0354 getrlimit(RLIMIT_STACK, 0xFFFFFFFF7FFFF448)     = 0
 0.0355 getcontext(0xFFFFFFFF7FFFF160)
 0.0358 context(3, 0xFFFFFFFF7F0C4EE0)
 0.0360 sysconfig(_CONFIG_SEM_VALUE_MAX)                = 2147483647
 0.0363 nanosleep(0xFFFFFFFF7FFFFAD0, 0x00000000)       = 0
 0.0366 _exit(4294969536)

It does the same thing. 

> > lib/xnanosleep.c currently assumes nanosleep works with any value that
> > can be fit into the struct timespec. For gnu+linux on a 
> > platform with 64 bit longs, this isn't true (it currently doesn't even
> > return and error but just silently integer-overflows, but I've
> > submitted a patch to make it error).
> 
> That doesn't sound right.  Why not just fix nanosleep so that it works
> instead?  It shouldn't be that hard.  There shouldn't be an arbitrary
> upper bound to the length of the sleep.

I agree that would be a pleasing solution, but since it'll stop the 
number of nanoseconds in the sleep from being exressible as a single
integer it's going to make a lot of code very unpleasant, and it's
certainly no small undertaking.

> Also, until the kernel bug gets fixed, what's the harm of leaving
> coreutils alone?  The bug occurs only for sleeps longer than about 68
> years, so it's not like this is a burning issue.

This turns a perfectly reasonable "while sleep inf; do done" to sleep
forever from a slightly unpleasant piece of idiom into a busy wait.
I'd say that's worth fixing.

-- 
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