On 30 August 2013 07:37, Glenn Fowler <[email protected]> wrote: > > On Fri, 30 Aug 2013 06:07:14 +0200 Cedric Blancher wrote: >> On 30 August 2013 06:01, Glenn Fowler <[email protected]> wrote: >> > >> > 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 > >> But it has been discussed and went through many discussions before >> Roland send it to the list. There has been a lot of thought behind >> that patch, more than I liked. > > some problems require more thought/discussion than others > part of the off list discussion between dgk and me is how to > abstract C features at the interpreter level > some interpreted languages give up on abstraction and expose way too much of > the C apis > > look how far mcilroy's elegant "foo | bar" has taken us > there's plenty more gems like that waiting for some thought to bring them to > light > > I know "(memory) address" in that patch raised a red flag
Would a patch without kill -Q acceptable? Ced -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
