Hello, On Thu, Jan 4, 2018 at 6:53 PM, Cathey, Jim <[email protected]> wrote:
> >Unconditionally sleeping when signals may arrive is a no-no. > > It used to be that sleep(3) was interruptible. Is this no longer the > case? Who broke libc, and when? > * sleep() in musl is implemented using nanosleep() [1]. * ucLibc-ng is using nanosleep() too [2], and implement a workaround for an old linux bug (it seems that this workaround is not needed) * and surpris, sleep() in the glibc is using... nanosleep() [3] Now, sleep() shall be interrupted by any signal who either has a handler in the thread or terminates the program [A]. The sames goes for nanosleep() [B]. So when you install a SIGCHLD handler, the signal will kill sleep(). Now, SIGCHLD is not catched by default (man 7 signal says the default is set to "ignore"). So while sleep() is still interruptible, it won't be if the delivered signal is SIGCHLD - unless you install a handler for this signal. Since busybox' init does not do that, then no, sleep() will not be interrupted in that case (and you face the problem Laurent describes). > > -- Jim > > Best regards, -- Emmanuel Deloget [1] https://git.musl-libc.org/cgit/musl/tree/src/unistd/sleep.c [2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/unistd/sleep.c#n74 [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sleep.c [A] http://pubs.opengroup.org/onlinepubs/9699919799/functions/sleep.html [B] http://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
