rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: John Mackin <mackin@vast.eecs.unsw.oz.au>
To: The rc Mailing List <rc@archone.tamu.edu>
Subject: Re: Bug in builtin wait when there are no kids?
Date: Wed, 2 Oct 1991 01:28:12 -0500	[thread overview]
Message-ID: <9110021628.4571.rc.babiv@vast.eecs.unsw.oz> (raw)
In-Reply-To: <9110011508.AA27149@litchi.bbn.com>

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.


  reply	other threads:[~1991-10-02  6:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-10-01 15:08 Rich Salz
1991-10-02  6:28 ` John Mackin [this message]
1991-10-01 15:30 Byron Rakitzis
1991-10-02  7:03 Byron Rakitzis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9110021628.4571.rc.babiv@vast.eecs.unsw.oz \
    --to=mackin@vast.eecs.unsw.oz.au \
    --cc=rc@archone.tamu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).