From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH v3 08/19] write_or_die: raise SIGPIPE when we get EPIPE
Date: Wed, 20 Feb 2013 14:01:14 -0800 [thread overview]
Message-ID: <20130220220114.GB24236@google.com> (raw)
In-Reply-To: <20130220215845.GB817@sigill.intra.peff.net>
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: 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
> actually wonder if we should simply exit(141) in the first place. That
> is shell exit-code for SIGPIPE death already (so it's what our
> run_command would show us, and what anybody running us through shell
> would see).
Yes, for the "should never happen" part. Raising a signal is nice
because it means the wait()-ing process can see what happened by
checking WIFSIGNALED(status).
Jonathan
next prev parent reply other threads:[~2013-02-20 22:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 19:51 [PATCHv3 0/19] pkt-line cleanups and fixes Jeff King
2013-02-20 19:53 ` [PATCH v3 01/19] upload-pack: use get_sha1_hex to parse "shallow" lines Jeff King
2013-02-20 19:54 ` [PATCH v3 02/19] upload-pack: do not add duplicate objects to shallow list Jeff King
2013-02-20 19:55 ` [PATCH v3 03/19] upload-pack: remove packet debugging harness Jeff King
2013-02-20 20:00 ` [PATCH v3 04/19] fetch-pack: fix out-of-bounds buffer offset in get_ack Jeff King
2013-02-20 20:00 ` [PATCH v3 05/19] send-pack: prefer prefixcmp over memcmp in receive_status Jeff King
2013-02-20 20:00 ` [PATCH v3 06/19] upload-archive: do not copy repo name Jeff King
2013-02-20 20:01 ` [PATCH v3 07/19] upload-archive: use argv_array to store client arguments Jeff King
2013-02-20 20:01 ` [PATCH v3 08/19] write_or_die: raise SIGPIPE when we get EPIPE Jeff King
2013-02-20 21:51 ` Jonathan Nieder
2013-02-20 21:58 ` Jeff King
2013-02-20 22:01 ` Jonathan Nieder [this message]
2013-02-20 22:03 ` Jeff King
2013-02-20 22:06 ` Jonathan Nieder
2013-02-20 22:12 ` Jeff King
2013-02-20 22:19 ` Junio C Hamano
2014-03-28 8:35 ` [BUG] MSVC: error box when interrupting `gitlog` by quitting less Marat Radchenko
2014-03-28 9:14 ` Marat Radchenko
2014-03-28 9:44 ` Jeff King
2014-03-28 10:07 ` Marat Radchenko
2014-03-28 10:19 ` Jeff King
2014-03-28 10:28 ` Johannes Sixt
2014-03-28 11:19 ` [PATCH] MSVC: link in invalidcontinue.obj for better POSIX compatibility Marat Radchenko
2014-03-28 18:27 ` Junio C Hamano
2014-03-28 18:46 ` Marat Radchenko
2014-03-28 19:06 ` Junio C Hamano
2014-03-28 20:08 ` [PATCH v2] " Marat Radchenko
2014-03-28 20:35 ` Junio C Hamano
2013-02-20 20:01 ` [PATCH v3 09/19] pkt-line: move a misplaced comment Jeff King
2013-02-20 20:01 ` [PATCH v3 10/19] pkt-line: drop safe_write function Jeff King
2013-02-20 20:02 ` [PATCH v3 11/19] pkt-line: provide a generic reading function with options Jeff King
2013-02-20 20:02 ` [PATCH v3 12/19] pkt-line: teach packet_read_line to chomp newlines Jeff King
2013-02-20 20:02 ` [PATCH v3 13/19] pkt-line: move LARGE_PACKET_MAX definition from sideband Jeff King
2013-02-20 20:02 ` [PATCH v3 14/19] pkt-line: provide a LARGE_PACKET_MAX static buffer Jeff King
2013-02-20 20:04 ` [PATCH v3 15/19] pkt-line: share buffer/descriptor reading implementation Jeff King
2013-02-22 11:22 ` Eric Sunshine
2013-02-20 20:06 ` [PATCH v3 16/19] teach get_remote_heads to read from a memory buffer Jeff King
2013-02-20 20:07 ` [PATCH v3 17/19] remote-curl: pass buffer straight to get_remote_heads Jeff King
2013-02-20 20:07 ` [PATCH v3 18/19] remote-curl: move ref-parsing code up in file Jeff King
2013-02-20 20:07 ` [PATCH v3 19/19] remote-curl: always parse incoming refs Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130220220114.GB24236@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).