Is this a deadlock waiting to happen?

Is this a deadlock waiting to happen?

[Bart Schaefer]

Ray wrote:

    body_list=( ${(@f)"$( highlight $filename )"} ) 2>&1 | read _err

I was surprised to find that both $body_list and $_err are set in the
current shell.  I had presumed that piping to read would cause the left
side to be forked and the right to be executed in the current shell.

And indeed if I change this to:

    body_list=( ${(@f)"$( highlight $filename )"} ) : 2>&1 | read _err

then both the assignment and the ":" command are forked off and only
$_err is available to the current shell.

In the former situation, is it not the case that if the output to stderr
is too large for the OS to buffer in the pipeline, zsh is going to be
deadlocked, because [in the example] "highlight" will be blocked writing
to stderr while zsh is blocked waiting to read stdout from $(...) ?

Where did we optimize out the fork?

Re: Is this a deadlock waiting to happen?

[Peter Stephenson]

On 14 Nov 2015 22:47, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Ray wrote: 
>
>     body_list=( ${(@f)"$( highlight $filename )"} ) 2>&1 | read _err 
>
> I was surprised to find that both $body_list and $_err are set in the 
> current shell.

There is a very longstanding set of cases where the fork happens in execcmd()  rather than up in execpline(), at the point where it would fork before an exec. I presume this is one of those. Then prefork()  substitutions are done first. I don't have the code with me but I think it's fairly tortuous (surprise).

pws