Jeff King writes:
> I am more concerned that the assertion is not "oops, another thread is
> doing something crazy, and it is a bug", but rather that there is some
> weird platform where SIG_DFL does not kill the program under SIGPIPE.
> That seems pretty crazy, though. I think I'd squash in some
On Wed, Feb 20, 2013 at 02:06:37PM -0800, Jonathan Nieder wrote:
> > I don't mind adding a "BUG: " message like you described, but we should
> > still try to exit(141) as the backup, since that is the shell-equivalent
> > code to the SIGPIPE signal death.
>
> If you want. :)
>
> I think caring a
Jeff King wrote:
> On Wed, Feb 20, 2013 at 02:01:14PM -0800, Jonathan Nieder wrote:
How about
die("BUG: another thread changed SIGPIPE handling behind my
back!");
to make it easier to find and fix such problems?
>>>
>>> You mean for the "should never happe
On Wed, Feb 20, 2013 at 02:01:14PM -0800, Jonathan Nieder wrote:
> >> How about
> >>
> >>die("BUG: another thread changed SIGPIPE handling behind my
> >> back!");
> >>
> >> to make it easier to find and fix such problems?
> >
> > You mean for the "should never happen" bit, not the fir
Jeff King wrote:
> On Wed, Feb 20, 2013 at 01:51:11PM -0800, Jonathan Nieder wrote:
>>> + if (err == EPIPE) {
>>> + signal(SIGPIPE, SIG_DFL);
>>> + raise(SIGPIPE);
>>> + /* Should never happen, but just in case... */
>>> + exit(141);
>>
>> How about
>>
>>
On Wed, Feb 20, 2013 at 01:51:11PM -0800, Jonathan Nieder wrote:
> > This distinction doesn't typically matter in git, because we
> > do not ignore SIGPIPE in the first place. Which means that
> > we will not get EPIPE, but instead will just die when we get
> > a SIGPIPE. But it's possible for a d
Jeff King wrote:
> The write_or_die function will always die on an error,
> including EPIPE. However, it currently treats EPIPE
> specially by suppressing any error message, and by exiting
> with exit code 0.
>
> Suppressing the error message makes some sense; a pipe death
> may just be a sign tha
7 matches
Mail list logo