From owner-freebsd-hackers@FreeBSD.ORG  Sun Mar 30 18:50:34 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3F2F537B401
	for <hackers@freebsd.org>; Sun, 30 Mar 2003 18:50:34 -0800 (PST)
Received: from priv-edtnes28.telusplanet.net (outbound04.telus.net
	[199.185.220.223])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7EEBC43FB1
	for <hackers@freebsd.org>; Sun, 30 Mar 2003 18:50:33 -0800 (PST)
	(envelope-from sh@bel.bc.ca)
Received: from REASON ([154.5.106.237]) by priv-edtnes28.telusplanet.net
          (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP
          id <20030331025032.JBXP4735.priv-edtnes28.telusplanet.net@REASON>
          for <hackers@freebsd.org>; Sun, 30 Mar 2003 19:50:32 -0700
Message-ID: <007e01c2f730$4b5863d0$0300000a@slugabed.org>
From: "Sean Hamilton" <sh@bel.bc.ca>
To: <hackers@freebsd.org>
References: <001101c2f71d$8d9e4fb0$0300000a@slugabed.org>
	<20030331023856.GL74971@dan.emsphone.com>
Date: Sun, 30 Mar 2003 18:50:30 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: Re: wait()/alarm() race condition
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2003 02:50:35 -0000

Dan Nelson wrote:
| Just make sure your signal handler has the SA_RESTART flag unset
| (either via siginterrupt() if the handler was installed with signal(),
| or directly if the signal was installed with sigaction() ), and the
| signal will interrupt the wait() call.

Er, I think you've missed my problem. Or I'm not getting your solution.

I'm concerned about this order of events:

- alarm()
- wait() returns successfully
- if (alarmed...) [false]
- SIGALRM is delivered, alarmed = true
- loop
- wait() waits indefinitely

This is incredibly unlikely to ever happen, but it's irritating me somewhat
that the code isn't airtight. Bad design. Surely there is some atomic means
of setting a timeout on a system call.

sh