On Wed, Aug 21, 2013 at 4:09 PM, David Korn <[email protected]> wrote: > cc: [email protected] > Subject: Re: Re: [ast-developers] [patch] kill(1) |sigqueue()| fixes+|EAGAIN| > handling etc. ... / was: Re: |sigqueue()| fixes+|EAGAIN| handling etc. ... > -------- > 2. Add -R to handle EAGAIN > I don't think that this is needed. EAGAIN should be handled > as it is with fork with an exponential back-off algorithm that > times out after around 30 seconds. EINTR will cause a retry > unless trapnote has pending trap or signal to process in which > case kill will fail.
I think I know why Roland added this option: 1. If the target process or thread is stopped it cannot consume signals. They just queue up. If the queue is full an attempt to sigqueue() one returns with EAGAIN and you have a variation of the Livelock [http://en.wikipedia.org/wiki/Deadlock#Livelock]. You can try to experiment with that by using ulimit -i 5. 2. Spinning with EAGAIN may not always be desirable for a realtime application. Realtime != fast, it must be able to guarantee to act in a determinable amount of time. The default case should be to spin with EAGAIN (after all, ksh93 is a high level language), but give the programmer the ability to do the EGAIN loop themselves. That's what we did until Roland invented the -R option. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
