Vassilii Khachaturov <[EMAIL PROTECTED]> wrote:
>> If I understand the original report, you can close this bug,
>> since sleep now accepts floating point numbers.
>
> The bug called for using the sleep system call instead of nanosleep,
> indeed assuming that sleep(1) is used with an integer argument. However, I
> wonder if anybody actually uses the less-than-a-second precision feature
> given the portability concerns (I have never seen a packaged shell script
> that does it). If you feel that the feature is useful,
> just close the bug. Otherwise, if you think that a less heavy binary (one
> that just does a single sleep syscall) would be appropriate, then the
> bug should remain. Maybe the coreutils should include the lighter one
> (the one the bug is calling for), and for somebody requiring the higher-
> precision sleep binary an alternative-creating package could be done
> (although that is a lot of work for nothing if nobody uses the noninteger
> argument shell syntax of this command).
Sorry, but reverting sleep(1) to 1-second (no floating-point argument)
resolution is not an option. Too many people have requested that feature.
I interpret this part of the bug report
(remember that it was against an older version of sleep
that still accepted only integer number of seconds):
* sleep(1) argument is in seconds, ferchrissake! If we really
want sub-microsecond accuracy we would need (aside of turning the kernel
into RT one and making sure that sleep(1) is locked in core) an argument
with comparable precision.
as saying that sleep should accept a higher-resolution (e.g., floating point)
description of the requested sleep interval.
If your concern is with the size of sleep's code,
then maybe you'd prefer usleep?
$ ls -go /usr/bin/usleep /bin/sleep
-rwxr-xr-x 1 14424 Jul 16 2004 /bin/sleep*
-rwxr-xr-x 1 2780 Jun 2 2001 /usr/bin/usleep*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
