From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from vast.eecs.unsw.oz.au ([129.94.128.185]) by archone.tamu.edu with SMTP id <18893>; Wed, 2 Oct 1991 01:38:49 -0500
Received: from chiton.eecs.unsw.OZ.AU by pearl.eecs.unsw.oz.au (5.65/1.34)
	id AA15171; Wed, 2 Oct 91 16:38:04 +1000
Received: by chiton (4.1/4.7)
	id AA04589; Wed, 2 Oct 91 16:37:52 EST (from mackin)
From: John Mackin <mackin@vast.eecs.unsw.oz.au>
Date: Wed, 2 Oct 1991 01:28:12 -0500
To: The rc Mailing List <rc@archone.tamu.edu>
Subject: Re: Bug in builtin wait when there are no kids?
In-Reply-To: <9110011508.AA27149@litchi.bbn.com>
Message-Id: <9110021628.4571.rc.babiv@vast.eecs.unsw.oz>
X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F
 k5[Ah<7xBWF<un6={nlL7Om5<0UsuHKjCxs)C$`DP.N'-LLb8=8)"a@d2bG-f7qD2AJ#UZ>-@-ru?&
 @4K4-b`ydd^`(n%Z{

Rich has come across one of the many ways to break rc's waiting.  I
wasn't going to talk about this on the list, since I believe that
it's not really the done thing, but as I have explained to Byron
how this needs to be fixed and he has ignored me, I've decided I
need to speak out.

The way rc waits now is totally bogus.  All it takes is an interrupt
at the wrong time and the data structures go to hell.  Another easy way
to provoke it is this (last tried in 1.1gamma):

; fn sigiot { /bin/echo pus; /bin/echo pus }
; kill -6 $pid

Infinite loop.

This really -must- be fixed.  Ignoring this issue isn't an acceptable
solution; neither is adopting the position that since there is no
mutual exclusion in, for example, malloc, the game is over anyway.
In a theoretical sense that is true, but the fact of the matter is
that rc is most likely to receive a signal during wait(), so it is
well worth the effort to use proper data structures that cannot
become corrupted under these conditions.

I do not claim that it is good to have to do this.  I believe that
the way the wait() system call works is quite bad, and presents
difficult problems for shell authors.  I do believe, notwithstanding
that, that it must be done.  Byron, I would appreciate a statement
as to your position on this matter; I know you don't want to do anything
to rc now beyond bug fixes, but I can't believe that you don't agree
that this is a bug.

OK,
John.