From owner-cvs-lib Sat May 17 23:39:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA13650 for cvs-lib-outgoing; Sat, 17 May 1997 23:39:49 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13632; Sat, 17 May 1997 23:39:18 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.5/8.8.5) id KAA00638; Sun, 18 May 1997 10:39:16 +0400 (MSD) Date: Sun, 18 May 1997 10:39:14 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Bruce Evans cc: peter@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen sleep.c In-Reply-To: <199705180129.LAA17474@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-lib@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 18 May 1997, Bruce Evans wrote: > 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! Yes. It is easy way to see this bug: sleep 1000 & kill -ALRM %1 old variant says: [1] Terminated New one says: [1] Alarm clock (don't forget to re-buid sleep(1), of course) But it is not the only difference. As I say, old sleep restarted again after signal != SIGALRM (f.e. SIGCHLD), but new sleep terminates! I suspect this thing break Apache. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/