From owner-freebsd-arch Thu Jan 24 1: 6:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id C9FDD37B404 for ; Thu, 24 Jan 2002 01:06:37 -0800 (PST) Received: from pool0373.cvx22-bradley.dialup.earthlink.net ([209.179.199.118] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Tfq7-0007bG-00; Thu, 24 Jan 2002 01:06:36 -0800 Message-ID: <3C4FCE98.2C0BE57E@mindspring.com> Date: Thu, 24 Jan 2002 01:06:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Nit in wait(2) man page? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > The wait(2) man page says: > > [EINTR] The call was interrupted by a caught signal, or the > signal did not have the SA_RESTART flag set. > > Should this be s/or/and/? Yes. Interrupted system calls do not return error codes if the restart flag is set, they are restarted, instead. I think you may need to be careful here, though, based on the interaction with threads. I'm not sure how the wrapped system calls find themselves restarted, if they are interrupted by a signal handler. In tehory, this should be transparent, but in practice, there is a heck of a lot of voodoo in the wrapper code to deal with masks and stuff, mostly to deal with the fact that system call restart is no longer the default behaviour, thanks to POSIX. The historical interface was to always restart system calls unless siginterrupt(2) has been called, and prior to the siginterrupt(2) being introduces (ULTRIX 4.1), the only way a signal could interrupt a system call was as a result of a longjmp(3) out of the signal handler, with a corresponding setjmp(3) before the system call. All in all, this was a much more UNIX-like behaviour (complex behaviour emergent from a small set of not-so-complex building blocks). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message