coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed ou


From: Arsen Arsenović
Subject: Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs
Date: Wed, 30 Nov 2022 13:42:21 +0100

Carl Edquist <edquist@cs.wisc.edu> writes:

> It sounds like one way or another you want to copy your endless but
> intermittent input to multiple output pipes, but you want to quit as soon as
> all the output pipes become broken.

Precisely.  The most important requirement there is that the tee-based
substitute imitates the lifetime of it's longest lived output.  Now I'm
thinking, maybe --pipe-check should also block SIGPIPE, to prevent the
race between poll, process death and write (which would result in the
process getting killed, as it'd happen right now, to see what I mean,
try ``tee >(sleep 100) >(:)'' and press enter after a bit; a race could
make --pipe-check behave like that).

I'll keep this in mind, for v2, which is currently waiting on me having
some time to research the portability of this whole thing, and for a
decision on whether to even include this feature is made.

> To me, tee sounds like exactly the place to do that.  Otherwise, you'd have to
> add the broken-pipe detection (as in your patch) to your own program, along
> with the rest of tee's basic functionality  :)
>
> It would be one thing if you controlled the programs that consume the input
> (you could have them handle 'heartbeats' in the input stream, and once these
> programs terminate, the heartbeats would trip on the broken pipe).  (However
> (in)elegant that becomes to implement...)
>
> But if you don't have control over that, the fundamental problem is detecting
> broken pipes *without writing to them*, and I don't think that can be solved
> with any amount of extra pipes and fd redirection...

I imagine that, technically, this is attainable by editing the process
substitutions involved to also signal the original process back;
however, this feels less elegant and generally useful than tee handling
this, given that tee's use-case is redirecting data to many places.

Thanks, have a nice day.
-- 
Arsen Arsenović

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]