NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
lib/58184: usleep persnicketiness is maybe not worth it
>Number: 58184
>Category: lib
>Synopsis: usleep persnicketiness is maybe not worth it
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: lib-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Apr 21 19:20:00 +0000 2024
>Originator: Taylor R Campbell
>Release: current, 10, 9, 8
>Organization:
The NetUSleep IBusywait Foundation
>Environment:
>Description:
Our usleep(3) implementation is persnickety about adhering to the letter of the former POSIX specification -- obsolescent 20 years ago in 2004, and removed from POSIX since then:
> int usleep(useconds_t useconds);
> ...
> The useconds argument shall be less than one million.
> ...
> ERRORS
> ...
> [EINVAL]
> The time interval specified one million or more microseconds.
https://pubs.opengroup.org/onlinepubs/009696899/functions/usleep.html
54 if (useconds >= 1000000) {
55 errno = EINVAL;
56 return (-1);
57 }
https://nxr.netbsd.org/xref/src/lib/libc/gen/usleep.c?r=1.20#54
This requires somewhat silly workarounds like the following sqlite3 commit:
https://www.sqlite.org/src/info/1f5ed852f25515bb
Maybe in the days of the SUSv2 in 1997 before usleep was marked obsolescent in POSIX, this was worthwhile. But today, it's not even in POSIX at all. Today, nobody expects the Spanish usleepition -- and since nobody bothers to check for usleep failure, instead of leading to noisy portability issue reports, it mostly leads to confusing failure modes like accidental busy-waits and generally poor performance on NetBSD for no obvious reason:
https://sqlite.org/forum/forumpost/7e50ced6a6
https://chaos.social/@dentangle/112309276051122420
>How-To-Repeat:
call usleep(1000000)
>Fix:
revert usleep.c rev. 1.16 (mostly)
Home |
Main Index |
Thread Index |
Old Index