wait()/alarm() race condition

[Sean Hamilton]

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