Zsh Mailing List Archive
Messages sorted by:
Re: night of the living dead (processes)?
- X-seq: zsh-workers 3635
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: TGAPE! <tgape@xxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: night of the living dead (processes)?
- Date: Wed, 26 Nov 1997 23:16:49 -0800
- In-reply-to: <199711262005.UAA10159@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <199711262005.UAA10159@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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
I suppose which is best depends on whether your performance is CPU-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
Messages sorted by: