From owner-cvs-lib Sun May 18 03:37:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA23965 for cvs-lib-outgoing; Sun, 18 May 1997 03:37:07 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA23958; Sun, 18 May 1997 03:36:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA01135; Sun, 18 May 1997 20:33:22 +1000 Date: Sun, 18 May 1997 20:33:22 +1000 From: Bruce Evans Message-Id: <199705181033.UAA01135@godzilla.zeta.org.au> To: ache@nagual.pp.ru, peter@spinner.dialix.com Subject: Re: cvs commit: src/lib/libc/gen sleep.c Cc: bde@zeta.org.au, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-lib@FreeBSD.org, peter@FreeBSD.org Sender: owner-cvs-lib@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >FWIW, I can't find any other sleep() implementation that always returns >zero like ours has done up to now. Ours was just buggy. >> In any case, _ignored_ signals should not interrupt sleep. > >Hmm.. Are we doing this?? Yes, tsleep() ignores them too. >Yes, if a SIGALRM arrives during sleep() from an outside source, we should >end the sleep rather than exit if the alarm signal isn't trapped. Only for backwards compatibility. >However, I don't see how to do this without races while using nanosleep(). >It could be possible to get a SIGALRM right after installing the handler >but before the nanosleep() starts. The old method doesn't have this problem :-(. sigsuspend()/sigpause() has exactly the right semantics for preventing the race. However, there's nothing you can do about SIGALRMs sent before the handler is installed. nanosleep() and the old sleep() have the same problem - alarms can't be relied on to terminate the sleep, because they may arrive before the sleep begins (perhaps due to scheduling delays). The best that you can do is to catch them so that you don't get killed. Bruce