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
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
