Date: Wed, 13 Aug 1997 01:30:43 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru> To: =?KOI8-R?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk> Cc: current@FreeBSD.ORG Subject: Re: Error in sleep ! Message-ID: <Pine.BSF.3.96.970813012151.29898A-100000@lsd.relcom.eu.net> In-Reply-To: <199708122105.XAA01981@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Aug 1997, Søren Schmidt wrote: > Yes but thats not documented anywhere... I just add a note to sleep.1 manpage. > ARG! my gripe was with sleep(_3_), if my process hangs in a sleep > (for good reason), and a signal to the process comes along, I want > the handler called, and then the sleep should continue. With the > new functionality this fails, and I have to put the sleep call in > a loop where it gets reiterated until the sleeping period actually > has expired. This strikes me as illogical and not very elegant, be > it posix or not... One small thing to consider: if sleep(3) will be uninterruptable, sleep(1) will be uninterruptable too (i.e. you'll can't break sleep(1) by pressing ^C), it broke sleep(1) POSIX requirement too: sleep(1) must do standard action on signals other than SIGALRM. Not breaking sleep(1) by ^C looks illogical and not very elegant too :-) For uninterrupted sleep you can use usleep(3) call in FreeBSD, since it isn't described by POSIX, it still remains uninterruptable by signals other than SIGALRM. -- Andrey A. Chernov <ache@null.net> http://www.nagual.pp.ru/~ache/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970813012151.29898A-100000>