Re: [PATCH] unblock and unignore SIGPIPE

2014-09-18 Thread Patrick Reynolds
On Wed, Sep 17, 2014 at 3:11 AM, Jeff King p...@peff.net wrote: Would we want to call it from external C commands, too? For the most part, git.c is the entry point for running git commands, and any sanitizing it does will be inherited by sub-commands. But it _is_ still legal to call dashed

Re: [PATCH] unblock and unignore SIGPIPE

2014-09-18 Thread Junio C Hamano
Thanks; just to save time, you may want to look at what has already been queued on 'pu'. On Thu, Sep 18, 2014 at 7:35 AM, Patrick Reynolds p...@github.com wrote: On Wed, Sep 17, 2014 at 3:11 AM, Jeff King p...@peff.net wrote: Would we want to call it from external C commands, too? For the most

Re: [PATCH] unblock and unignore SIGPIPE

2014-09-17 Thread Jeff King
On Tue, Sep 16, 2014 at 02:43:43PM -0700, Junio C Hamano wrote: +/* un-ignore and un-block SIGPIPE */ +void sanitize_signals(void) +{ + sigset_t unblock; + + sigemptyset(unblock); + sigaddset(unblock, SIGPIPE); + sigprocmask(SIG_UNBLOCK, unblock, NULL); +

Re: [PATCH] unblock and unignore SIGPIPE

2014-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: I see in your proposed patch below you put them into t. I wonder if t0005 would be a more obvious place. Yup. That is a good idea. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

Re: [PATCH] unblock and unignore SIGPIPE

2014-09-16 Thread Junio C Hamano
Patrick Reynolds patrick.reyno...@github.com writes: Blocked and ignored signals -- but not caught signals -- are inherited across exec. Some callers with sloppy signal-handling behavior can call git with SIGPIPE blocked or ignored, even non-deterministically. When SIGPIPE is blocked or

Re: [PATCH] unblock and unignore SIGPIPE

2014-08-21 Thread Patrick Reynolds
On Sun, Aug 17, 2014 at 8:14 PM, Eric Wong normalper...@yhbt.net wrote: But unicorn would ignore SIGPIPE it if Ruby did not; relying on SIGPIPE while doing any multiplexed I/O doesn't work well. Exactly. Callers block SIGPIPE for their own legitimate reasons, but they don't consistently

Re: [PATCH] unblock and unignore SIGPIPE

2014-08-17 Thread Eric Wong
Patrick Reynolds patrick.reyno...@github.com wrote: But in the real world, several real potential callers, including Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE ignored. s/Unicorn/Ruby/ But unicorn would ignore SIGPIPE it if Ruby did not; relying on SIGPIPE while

[PATCH] unblock and unignore SIGPIPE

2014-08-14 Thread Patrick Reynolds
Blocked and ignored signals -- but not caught signals -- are inherited across exec. Some callers with sloppy signal-handling behavior can call git with SIGPIPE blocked or ignored, even non-deterministically. When SIGPIPE is blocked or ignored, several git commands can run indefinitely, ignoring