Date: Mon, 7 Jul 1997 01:19:55 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru> To: Peter Wemm <peter@spinner.dialix.com.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: sleep (was Re: Application os version compatibility?) Message-ID: <Pine.BSF.3.96.970707010754.17216A-100000@lsd.relcom.eu.net> In-Reply-To: <199707061339.VAA23239@spinner.dialix.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.970707010754.17216A-100000>