From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 18070 invoked from network); 5 Dec 1997 05:17:39 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 5 Dec 1997 05:17:39 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id XAA03386;
	Thu, 4 Dec 1997 23:51:48 -0500 (EST)
Resent-Date: Thu, 4 Dec 1997 23:51:48 -0500 (EST)
From: TGAPE! <tgape@cyberramp.net>
Message-Id: <199712042352.XAA32025@dal-tsa17-60.cyberramp.net>
Subject: workaround for Re: night of the living dead (processes)?
To: schaefer@brasslantern.com (Bart Schaefer)
Date: Thu, 4 Dec 1997 23:52:03 +0000 (GMT)
Cc: tgape@cyberramp.net, zsh-workers@math.gatech.edu
In-Reply-To: <971126231649.ZM786@candle.brasslantern.com> from "Bart Schaefer" at Nov 26, 97 11:16:49 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"f8bkQ.0.rq.aXuXq"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3646
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

I'm posting this under the delusion that some other people other than
myself might be interested in it.  Sorry to everyone who isn't...

Bart Schaefer wrote:
> On Oct 22, 12:14am, TGAPE! wrote:
>} Subject: night of the living dead (processes)?
>}
>} Is there any way to handle the children produced in the <() construct
>} (and similar ones, as well) in zsh, instead of tossing them to init?
>
> The only way a process should ever get "tossed" is if its parent exits
> without wait()ing for it.  The top-level zsh obviously isn't exiting (is
> it?), so that must mean zsh fork()ed and then the subshell fork()ed again
> before the orphaned process was finally exec()d.  That in turn means (at
> least I think it must) that you have a pipeline inside the <(...).
>
> The only way to avoid orphaning those jobs would be to have intermediate
> subshells fork() an additional time, rather than exec()ing the last job
> in the pipeline directly, and then hang around doing nothing but wait()
> until all the piped jobs have exited.  Only init and the immediate parent
> of a job may wait() for it.  So you either have to burn an extra slot in
> the process table (and swap space for a duplicate of the shell) for the
> full duration of every subshelled pipeline, or do what zsh (and bash, it
> seems) does.

Right.  *BUT*, zsh, bash, and ksh all have a fix for this - shell
functions.  Simply make a shell function to do your pipeline - that will
give you your extra shell process.

For example, change
    m=0; while read x y
    do
      ((t = $(ls -l $x | awk '{ print $5 }') - $(ls -l $y | awk '{print $5}')))
      if (($t > $m)); then
        m=$t
      fi
    done < u;echo $m
to
    function getsize() {
      ls -l $1 | awk '{ print $5 }'
    }
    m=0; while read x y
    do
      ((t = `getsize $x` - $(getsize $y)))
      if (($t > $m)); then
        m=$t
      fi
    done < u;echo $m


Now, I'm sure, just like with everything else I do, there's an even
better way to do this.  However, this works, and doesn't thrash init.

> I suppose which is best depends on whether your performance is CPU-limited
> or process-space-limited.

Extra swapping takes *far* less time than init's thrashing, unless your
machine is so busy that virtually every page of memory is active.  If
that's the case, you need help.  (At least, on my system, the thing's
been utterly more responsive using this method - even my other processes
run much better...  Your mileage might vary, but I don't think it'll vary
significantly.  Still, this is suffering the delusion you'd have done
something this insane, but we all have our delusions.)

Ed