bug#9089: [1003.1(2008)/Issue 7 0000205]: Shell pipeline connection requirement too vague

[Eric Blake]

According to David Korn on 1/7/2010 1:46 PM:
> cc: address@hidden address@hidden
> Subject: Re: Re: [1003.1(2008)/Issue 7 0000205]: Shell pipeline connection 
> requirement too vague

Reviving an older Austin Group conversation, and adding GNU coreutils in cc:

> --------
> 
>> This topic was discussed during today's conference call.
>>
>> We did not reach any conclusion about how this should be resolved yet.
>>
>> But, as noted on a few messages on this alias on this topic, there was
>> agreement that many applications do depend on pipe behaviors (write
>> atomicity guarantees, generation of SIGPIPE signals, etc.) that are not
>> satisfied by a socketpair implementation.  We would much prefer to see
>> an explicit option or syntax extension to enable higher performance
>> pipes rather than having "|" silently provide behavior that is not what
>> would be expected from a pipe created by a call to pipe().
> If recv() were required to work on pipes, there would be no need
> for the shell to use socketpair().  On Linux (and I don't know if
> there are any other systems), recv() doesn't work on pipes.  However,
> socketpair() does generate SIGPIPE when writing to socket created
> by socketpair that doesn't have a reader.  I don't know whether
> sockpair() file descriptors have the same atomicity requirements
> as pipes, but I have never seen a bug filed against ksh along
> this line.

Here's an example bug report where ksh behavior is observable, resulting
in a bug report being issued against coreutils.  That is, using
socketpair() instead of pipe() risks introducing ECONNRESET instead of
EPIPE when the consumer goes away, with the result being subject to
scheduling races:
http://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00085.html.

Is cat required to treat ECONNRESET like EPIPE, or is ksh at fault here
for using socketpair()?

> The only problem with socketpair on Linux is that files that inherit
> a socketpair file descriptor cannot use /dev/fd/n to get an open
> file descriptor.  I think that this is a Linux bug.
>>
>> We understand that pipes require single-byte reads (at least for
>> non-STREAMs based pipes) and that this does provide a significant
>> performance penalty in some circumstances.  The committee would be
>> happy to consider enhancement requests to add relative seeks on pipes
>> up to the last read() (as David Korn mentioned in email sequence
>> #13298) or other features that would help alleviate this issue.
> As long as the standard requires a way to peek ahead or to
> seek back to the previous read(), then the shell can revert back
> to using pipes.
> The simplest change to the standard would be to require that recv()
> work on pipes as well as sockets.

Is this something we should pursue further, to get to a point where pipe()
is not so bad to use?

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

signature.asc
Description: OpenPGP digital signature