Date: Sun, 30 Mar 2003 18:50:30 -0800 From: "Sean Hamilton" <sh@bel.bc.ca> To: <hackers@freebsd.org> Subject: Re: wait()/alarm() race condition Message-ID: <007e01c2f730$4b5863d0$0300000a@slugabed.org> References: <001101c2f71d$8d9e4fb0$0300000a@slugabed.org> <20030331023856.GL74971@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007e01c2f730$4b5863d0$0300000a>