tech-kern archive

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

Re: SIGPIPE-equivalent before writing?



> Sometimes I run (say) git log or hg log with a query that takes a
> long time to produce output into my pager, less(1).

> When I type `q' to exit the pager, sometimes the producer is still
> _computing_ but not _writing_ output.  In this case, it doesn't
> notice that its job is done until it next tries to _write_ output and
> the write fails with EPIPE/SIGPIPE.  So the producer just hangs doing
> computation until it has another byte of output to write -- which
> will be summarily discarded as soon as it is written.

True.

I know of no fix with current semantics, especially because the
distinction between "reader has exited, writer should exit immediately"
and "reader has exited, writer should compute to finish and then exit"
does not, I think, exist at any layer below the human layer.

To fix this right, you would need either

(a) Programs (somehow) declare whether reader-goes-away should produce
an *immediate* SIGPIPE-or-moral-equivalent, or whether it should wait
until/unless output is attempted.  It's open for debate whether this
declaration is done by the reader process, the writer process, the
shell, or what.

(b) There are two kinds of pipes, one of which has the current
semantics and the other has "immediate SIGPIPE-o-m-e" semantics,
presumably with some shell syntax controlling which one you get.

There is actually a third alternative, but focusing on the semantics of
the pipe (or other communications channel) obscures it:

(c) Some way to tell the shell that if *this* process dies, the rest of
the job is to be silently and summarily killed - this would then be
applied to the less process.

I don't see any good easy answers.  But then, it's a hard problem,
because it depends critically on information that, as I remarked above,
I think doesn't exist outside human minds - though in some cases a
reasonable approximation may be doable.  And when the communications
channel isn't a pipe but instead is a TCP connection or the like it's
harder, because then we quite possibly have no control over the other
end.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index