On Fri, 30 Aug 2013 04:04:34 +0200 Cedric Blancher wrote: > On 22 August 2013 00:35, Irek Szczesniak <[email protected]> wrote: > > 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.
> That was the reason. So -C has a use and -R has a rightful use, too > but the discussion is moot as the patch wasn't taken for > ast-ksh.2013-08-29. So again a shell where kill -q doesn't work in a > production environment. Which drives me seriously crazy. > I start to understand the rise of perl (which ksh93 could've easily > crushed): they just take patches in time while ksh93 delays them over > and over and over again some patch proposals require thought before making it into a release discussion is part of that process _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
