Re: process substitution and Ctrl-C

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2010-08-20 01:19:05 -0700, Bart Schaefer wrote:
> The process substitution can't really be synchronous in the sense of
> sequential with respect to the rest of the job.  The intention is to
> run in parallel so that multios can send data to many processes at
> once.  I think the rest of the behavior was ill-defined side-effect.

I don't think this is specific to process substitution. This should
also be the case for pipelines, such as:

  prg1 | prg2 | prg3 | prg4

All of the should be run in parallel to avoid a possible deadlock
due to buffering (and this should also be faster on today's desktop
machines, which have several cores). But as far as I can see, a
Ctrl-C interrupts all of them.

> On Aug 19, 11:17pm, Vincent Lefevre wrote:
> } However there's a race condition, IMHO. In fact, even without a signal
> } to the main process. For instance, if you consider:
> } 
> }   ls >>(cat -n)
> } 
> } then the zsh prompt for the next command is displayed before "cat -n"
> } finishes. Does this mean that process substitution should not be used
> } for filtering, except when an end marker is used (as in the example
> } at the end of my message)?
> 
> I'm not sure what question you're asking, [...]

What I mean here is: the problem is that the main shell doesn't wait
for "cat -n" to finish. This means that on a typical machine, the zsh
prompt will here be displayed before the "cat -n" output. This should
be more clear with:

  ls >>(sleep 2; cat -n)

I would like the same behavior as:

  { ls } >>(sleep 2; cat -n)

> } For instance:
> } 
> }   { ls } >>(while read line; do sleep 1; echo $line; done)
> } 
> } outputs one line each second, and the main process is blocked as
> } wanted; but if one does a Ctrl-C, the main process is terminated
> } and one gets the prompt while the substituted process still outputs
> } the remaining lines each second. I don't think this is the behavior
> } that one expects.
> 
> As noted above, that's the only behavior that could be accomodated in
> the original code base ... so it _is_ what someone who has been using
> zsh since 1993-ish would expect. :-)

I think the average user would expect process substitution to behave
a bit like pipes w.r.t. signals, e.g. like:

  ls | while read line; do sleep 1; echo $line; done

The fact that the right part is in the foreground doesn't matter.
One can see that everything is killed with a more complex one:

  { echo foo; sleep 5; echo bar } | \
  { while read line; do sleep 1; echo $line; done; echo blah >&2 } | \
  { sleep 10; read a; echo $a; sleep 2; cat }

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)