Re: [PATCH v3 01/10] built-in add -i/-p: treat SIGPIPE as EOF

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

 



On Fri, Jan 17, 2020 at 03:32:36PM +0100, SZEDER Gábor wrote:

> On Mon, Jan 13, 2020 at 06:04:17PM +0100, SZEDER Gábor wrote:
> > and 'GIT_TEST_ADD_I_USE_BUILTIN=1 ./t3701-add-interactive.sh -r 39,49'
> > fails with:
> > 
> >   + test_must_fail force_color git add -p
> >   about to run diffFilter
> >   attempting to xwrite() 224 bytes to a fd with revents flags 0x4
> >   test_must_fail: died by signal 13: force_color git add -p
> > 
> > I don't understand why we get SIGPIPE right away instead of some error
> > that we can act upon (ECONNRESET?).
> 
> Doh', because it's a pipe, not a socket, that's why.  pipe(7):
> 
>   "If all file descriptors referring to the read end of a pipe have
>    been closed, then a write(2) will cause a SIGPIPE signal to be
>    generated for the calling process."
> 
> So ECONNRESET is definitely not the right error to set on POLLERR,
> though I'm still not sure what the right one would be (perhaps
> EPIPE?).

Yes, if SIGPIPE is ignored, then that write() would produce EPIPE. So if
you're trying to emulate it via POLLERR, that would be accurate. Of
course it could fail for _other_ reasons, and I don't think we'd know
what those are without actually calling write(). Practically speaking,
though, if we know it's a pipe with a valid descriptor then any error is
basically equivalent to EPIPE (we don't care how, but for whatever
reason we couldn't write to the other end).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux