From owner-freebsd-current Tue Aug 12 14:41:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22859 for current-outgoing; Tue, 12 Aug 1997 14:41:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA22847 for ; Tue, 12 Aug 1997 14:41:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA07747; Tue, 12 Aug 1997 14:35:24 -0700 From: Terry Lambert Message-Id: <199708122135.OAA07747@phaeton.artisoft.com> Subject: Re: Error in sleep ! To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 14:35:24 -0700 (MST) Cc: sos@sos.freebsd.dk, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 01:12:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Type "man siginterrupt". > > > > Hmm, then that man page is in error too in -current :( > > This man page have nothing common with sleep signals interruption which > directly required by POSIX in any case. The man page is for the BSD'ism of "siginterrupt", which was introduced in Ultrix. By default, in traditional BSD, after a signal, the call was restarted. This man page is incorrect about the default for FreeBSD; so is the signal man page. However, the function operates as expected, and can turn on call restart. There are *also* POSIX mechanisms to turn on call restart on a per-signal basis (man sigaction; look for SA_RESTART). The difference is that historically BSD programs will expect the call to restart, and historically System V programs will expect the call to return EINTR (and the programmer to garbage up his code and his libc with a bazillion checks for EINTR that he really doesn't want to have to make). In BSD's 4.2 and prior (except Ultrix), the lack of a siginterrupt() was handled by setjmp() in the code and longjmp() in the handler to prevent call restart. This was usually used in combination with an alarm() call... mostly for things like device open() timeouts, etc.. One hopes to God that whoever turned on POSIX behaviour as the default patched each and every lib(3) call that is supposed to act atomic to correctly deal with idempotence across multiple system calls for a supposedly atomic operation (for example, an alarm firing and interrupting an opendir() operation with an allocation made, but the first getdents() not performed, etc.). Otherwise, we are just waiting for all hell to break loose... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.