From owner-freebsd-hackers Sun Jul 6 14:20:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA06619 for hackers-outgoing; Sun, 6 Jul 1997 14:20:42 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06608 for ; Sun, 6 Jul 1997 14:20:38 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.6/8.8.5) id BAA17383; Mon, 7 Jul 1997 01:19:56 +0400 (MSD) Date: Mon, 7 Jul 1997 01:19:55 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Peter Wemm cc: freebsd-hackers@FreeBSD.ORG Subject: Re: sleep (was Re: Application os version compatibility?) In-Reply-To: <199707061339.VAA23239@spinner.dialix.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Jul 1997, Peter Wemm wrote: > I'm not quite sure I follow you there.. I once talked about how using > plain nanosleep() as a replacement for sleep() is incompatable with some > things that depeneded on the SIGALRM eating semantics, and that one way > around it was to build make a merged sigprocmask/nanosleep syscall which > is basically "wait for specific signals or timeout, whichever comes first" > - this is what is in the tree at present. I also talked about using I mean present code. If SIGALRM is already ignored, you _not_ allow it while sleep() called i.e. not install signal handler for it. Another sleep() implementations like our previous one or GNU one allows it. I think this optimization gains nothing but may cause incompatibilities. > another syscall to directly implement the sleep(3)/usleep(3) semantics, > perhaps called nsleep(), which has the same args as nanosleep() (ie: > requested and returned times). What were you thinking of? Yes, such code will be better indeed, but it is separate issue, I talk about just bugfix to current code now. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/