Date: Sun, 30 Mar 2003 20:04:15 -0800 From: "Sean Hamilton" <sh@planetquake.com> To: <hackers@freebsd.org> Subject: Re: wait()/alarm() race condition Message-ID: <009301c2f73a$98d2c970$0300000a@slugabed.org> References: <001101c2f71d$8d9e4fb0$0300000a@slugabed.org><20030331023856.GL74971@dan.emsphone.com><007e01c2f730$4b5863d0$0300000a@slugabed.org> <20030331033643.GO74971@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: | In the last episode (Mar 30), Sean Hamilton said: || I'm concerned about this order of events: || || - alarm() || - wait() returns successfully || - if (alarmed...) [false] || - SIGALRM is delivered, alarmed = true || - loop || - wait() waits indefinitely | | A cleaner solution would be to use ualarm(60000,1000) or setitimer() | to do this (replacing the alarm(60) call outside the handler). This looks like the way to go. "cleaner" is certainly relative here, but it's quite likely this hack never comes up in the lifetime of the program. I've inserted a printf just in case. (slight grin) This is my first time dealing with signals... they seem to lack the elegance most of Unix offers. Perhaps that's just my inexperience speaking. sh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?009301c2f73a$98d2c970$0300000a>