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

Ced
-- 
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to