From owner-freebsd-current Tue Aug 12 14:30:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22117 for current-outgoing; Tue, 12 Aug 1997 14:30:58 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA22110 for ; Tue, 12 Aug 1997 14:30:54 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA00190; Wed, 13 Aug 1997 01:30:44 +0400 (MSD) Date: Wed, 13 Aug 1997 01:30:43 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: current@FreeBSD.ORG Subject: Re: Error in sleep ! In-Reply-To: <199708122105.XAA01981@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 http://www.nagual.pp.ru/~ache/