From owner-cvs-lib  Sun May 18 01:41:52 1997
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id BAA20502
          for cvs-lib-outgoing; Sun, 18 May 1997 01:41:52 -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 BAA20444;
          Sun, 18 May 1997 01:41:08 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA30604; Sun, 18 May 1997 18:38:59 +1000
Date: Sun, 18 May 1997 18:38:59 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705180838.SAA30604@godzilla.zeta.org.au>
To: bde@zeta.org.au, peter@spinner.dialix.com
Subject: Re: cvs commit: src/lib/libc/gen usleep.c
Cc: 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

>> Where do those semantics appear?  The old behaviour was to return
>> early.  The man page said otherwise, but so does the BSD4.4-Lite man
>  ^^^^^
>Are you sure of that?  Both sleep() and usleep() do a 'while
>(!ringring) sigpause(...)'..  To my reading, it won't return early ever...

I haven't read the sources lately, but the example

	alarm(1);
	sleep(2);

has been been returning early (and not returning the remaining time so it
has been on my bug list) for years.

Erm, ringring is set after the first SIGALRM is caught, so sleep() and
usleep() return after the first alarm.  The loop prevents returning after
other signals are caught.  Catching alarms prevents external SIGALRMs
from killing the process.

POSIX.1 seems to specify returning early from sleep() whenever a signal
(of any type) is caught.

Bruce