Re: Forking earlier for background code

[Vin Shelton <acs@alumni.princeton.edu>]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

I really think 5.5.2 should go out with only 5.5.1 + the signals.c change
first.

My $.02.

  - Vin

On Fri, Apr 20, 2018 at 6:01 AM, Peter Stephenson <p.stephenson@samsung.com>
wrote:

> (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
>