Re: Forking earlier for background code

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Fri, 20 Apr 2018 10:28:39 +0100
Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> It may well be possible to expand the logic to track down other cases
> where we know we can know we're going to need to fork, so can do so
> early to get fewer side effects (and slightly optimise the main
> shell).

I've been working on this, and as it's kind of interesting I think I'm
going to push my additional work on a branch called fork_early.  The
commit log entries are fairly descriptive, but here's a summary of what
I've done.

- Move the early fork even earlier --- the code immediately above it was
to do with initial examination of command line arguments, and the
new fork code deals exactly with the cases where we don't need to know
this.

- _exit if we forked and were going to return early from
execcmd_exec().  This shows up particularly in one case with the
preceding change --- namely assignments.

- As suggested, remove the previous code in the caller that did the fork
there if we recognised early this was code to run within the shell but
in an early part of the pipeline.  This is now redundant.  (I'm
wondering if this special code was there so that things like "foo=bar
&", which would have polluted the main shell, didn't push the original
problem beyond the pain barrier --- i.e. it was always just a partial
workaround.)

- That change revealed two other things that needed doing.  First, set
"last1" when we do the early fork so that subsequent code in the forked
shell knows we are going to exit.  This was revealed by the failure of a
test that sets an EXIT trap in the left hand side of a pipeline.
(Existing exit traps are cleared here, but it's possible to set a new
one and it should go off when the forked shell exits.)

- Second, Bart's woraround in zsh-wrokers/32171 for a leaked fd needed
rewriting.  The change is to ensure we always close the pipe fd that's not
needed in the forked code when we fork (i.e. the input side of the pipe
on the LHS --- the output side on the RHS was simpler and always managed
OK).  This seems reasonably transparent so I hope it's not going to lead
us down a blind alley (Bart added an explicit test for the case that was
failing).

We could probably do with some tests, although testing with background
code is a pain.

pws