Re: Forking earlier for background code

[Peter Stephenson <p.stephenson@samsung.com>]

(Sorry about multiple messages, but I'm sure you're fascinated...)

On Fri, 20 Apr 2018 10:28:39 +0100
Peter Stephenson <p.stephenson@samsung.com> 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).
>...
> So I think if "last1" is zero and "output" is non-zero we might be
> able to fork early, perhaps?

If you want to play along at home with step 1 here, try the following.

As far as I can see, we don't need to take special account of "exec"
here.  For the pipeline to work we always need to fork even if the
command has the "exec" keyword in front (same true of "&", in fact).


diff --git a/Src/exec.c b/Src/exec.c
index 1b622d5..768e3ef 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -3146,10 +3146,11 @@ execcmd_exec(Estate state, Execcmd_params eparams,
     esprefork = (magic_assign ||
 		 (isset(MAGICEQUALSUBST) && type != WC_TYPESET)) ?
 		 PREFORK_TYPESET : 0;
-    if (how & Z_ASYNC) {
+    if ((how & Z_ASYNC) || (output && !last1)) {
 	/*
-	 * If running in the background, we don't need any of
-	 * the rest of this functino to affect the state in the
+	 * If running in the background, or not the last command in a
+	 * pipeline and not already forked, we don't need any of
+	 * the rest of this function to affect the state in the
 	 * main shell, so fork immediately.
 	 *
 	 * In other cases we may need to process the command line

pws