From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 21:49:55 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 AD65837B401 for ; Sun, 30 Mar 2003 21:49:54 -0800 (PST) Received: from thought.holo.org (h-68-166-32-19.SNVACAID.covad.net [68.166.32.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 127E643FAF for ; Sun, 30 Mar 2003 21:49:54 -0800 (PST) (envelope-from bwb@holo.org) Received: from localhost (localhost [127.0.0.1]) by thought.holo.org (8.12.9/8.12.8) with ESMTP id h2V5nAVA066339; Sun, 30 Mar 2003 21:49:10 -0800 (PST) (envelope-from bwb@holo.org) Date: Sun, 30 Mar 2003 21:49:10 -0800 (PST) From: Brian Buchanan To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= In-Reply-To: <20030330191611.J1122@atlas.home> Message-ID: <20030330214750.A65240-100000@thought.holo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT cc: hackers@freebsd.org cc: Sean Hamilton 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 05:49:59 -0000 On Sun, 30 Mar 2003, [ISO-8859-1] Mikko Työläjärvi wrote: > On Sun, 30 Mar 2003, Sean Hamilton wrote: > > > 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. > > My stock solution to this kind of problem is to turn those pesky > signals into I/O and use an old fashioned select() loop to handle > them; create a pipe(2), let signal handlers write one-byte "messages" > (the signal number) into the pipe and then use select() to dequeue the > events (signals) from the pipe. > > Select() has a timeout parameter you can play with to your hearts > content, and provided you don't overflow the pipe, no events will > get lost. You'd have to install a hander for SIGCHLD, of course. Or how about kqueue(2) with EVFILT_SIGNAL. That would seem to be a more elegant solution. No signal handlers or alarm() required. -Brian -- Brian Buchanan, CISSP bwb@holo.org -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org