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 that the other side is not
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 that the
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 default
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
die(BUG:
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 first part, right? I
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 happen bit, not the first part, right?
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 about
Jeff King p...@peff.net 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
8 matches
Mail list logo