[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: |
Mon, 28 Aug 2006 09:12:27 +0200 |
User-agent: |
Mutt/1.5.9i |
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