zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: TGAPE! <tgape@cyberramp.net>, zsh-workers@math.gatech.edu
Subject: Re: night of the living dead (processes)?
Date: Wed, 26 Nov 1997 23:16:49 -0800	[thread overview]
Message-ID: <971126231649.ZM786@candle.brasslantern.com> (raw)
In-Reply-To: <199711262005.UAA10159@dal-tsa15-34.cyberramp.net>

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.

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

} I'm running ZSH_VERSION 3.1.1.  I contemplated upgrading to 3.0.5

Changing to 3.0.5 would not alter this process management behavior.

> but it's
} slower for all of my longest running tasks (**/glob stuff, and such) as
} well as all other so I did not make install.

What do you mean "as well as all other"?

Can you give some more specific examples, and some statistics?  Is there
an earlier 3.0.x that shows the performance you expect, or is there some
reason why all 3.1.y should be faster than 3.0.x?  I haven't noticed any
particular difference from earlier 3.0s with 3.0.5.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


  reply	other threads:[~1997-11-27  7:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-10-22  0:14 TGAPE!
1997-11-27  7:16 ` Bart Schaefer [this message]
1997-12-04 23:52   ` workaround for " TGAPE!
  -- strict thread matches above, loose matches on Subject: below --
1997-10-22  0:14 Ed Grimm

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=971126231649.ZM786@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=tgape@cyberramp.net \
    --cc=zsh-workers@math.gatech.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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).