From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 19:36:45 2003 Return-Path: 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 7D81E37B401 for ; Sun, 30 Mar 2003 19:36:45 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9D0D43F85 for ; Sun, 30 Mar 2003 19:36:44 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h2V3ahYP092682; Sun, 30 Mar 2003 21:36:43 -0600 (CST) (envelope-from dan) Date: Sun, 30 Mar 2003 21:36:43 -0600 From: Dan Nelson To: Sean Hamilton Message-ID: <20030331033643.GO74971@dan.emsphone.com> References: <001101c2f71d$8d9e4fb0$0300000a@slugabed.org> <20030331023856.GL74971@dan.emsphone.com> <007e01c2f730$4b5863d0$0300000a@slugabed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007e01c2f730$4b5863d0$0300000a@slugabed.org> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 03:36:46 -0000 In the last episode (Mar 30), Sean Hamilton said: > 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 You can probably do something like "alarm(1);" at the top of your handle_sigalarm function. That way after 60 seconds the alarm will fire every second until cleared. A cleaner solution would be to use ualarm(60000,1000) or setitimer() to do this (replacing the alarm(60) call outside the handler). > 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. -- Dan Nelson dnelson@allantgroup.com