From owner-cvs-lib  Sat May 17 18:31:50 1997
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA23935
          for cvs-lib-outgoing; Sat, 17 May 1997 18:31:50 -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 SAA23892;
          Sat, 17 May 1997 18:31:22 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id LAA17474; Sun, 18 May 1997 11:29:42 +1000
Date: Sun, 18 May 1997 11:29:42 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705180129.LAA17474@godzilla.zeta.org.au>
To: ache@nagual.pp.ru, peter@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/gen sleep.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>BTW, it seems I find possible reason (but not test it yet).  It looks like
>old sleep stops only by SIGALRM (sigpause in while loop) but new one stops
>by _any_ signal, isn't it? 

One difference is that non-defaulted SIGALRMs now kill the process
instead of terminating the sleep.  This breaks sleep(1).  POSIX.1 may
allow either behaviour (the behaviour is mostly unspecified so that BAD
historiclal implementations using alarm() are standard).  In particular,
if SIGALRM is not generated be a previous call to alarm() and SIGALRM is
not being ignored or blocked, then it is explicitly unspecified whether
the signal has any effect other than causing sleep() to return.  The case
of SIGALRMs generated by alarm()s seems to be implicitly unspecified!

Bruce