write_or_die: handle EPIPE in async threads
authorJeff King <peff@peff.net>
Wed, 24 Feb 2016 07:40:16 +0000 (02:40 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 25 Feb 2016 21:51:45 +0000 (13:51 -0800)
commit9658846ce3d379b9ff8010a2ed326fcafc10eb82
tree815ab2d39efc3f4f591861dd43f050e5913a794e
parent326e5bc91eecf73234ead29636207bc516573e79
write_or_die: handle EPIPE in async threads

When write_or_die() sees EPIPE, it treats it specially by
converting it into a SIGPIPE death. We obviously cannot
ignore it, as the write has failed and the caller expects us
to die. But likewise, we cannot just call die(), because
printing any message at all would be a nuisance during
normal operations.

However, this is a problem if write_or_die() is called from
a thread. Our raised signal ends up killing the whole
process, when logically we just need to kill the thread
(after all, if we are ignoring SIGPIPE, there is good reason
to think that the main thread is expecting to handle it).

Inside an async thread, the die() code already does the
right thing, because we use our custom die_async() routine,
which calls pthread_join(). So ideally we would piggy-back
on that, and simply call:

  die_quietly_with_code(141);

or similar. But refactoring the die code to do this is
surprisingly non-trivial. The die_routines themselves handle
both printing and the decision of the exit code. Every one
of them would have to be modified to take new parameters for
the code, and to tell us to be quiet.

Instead, we can just teach write_or_die() to check for the
async case and handle it specially. We do have to build an
interface to abstract the async exit, but it's simple and
self-contained. If we had many call-sites that wanted to do
this die_quietly_with_code(), this approach wouldn't scale
as well, but we don't. This is the only place where do this
weird exit trick.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command.c
run-command.h
write_or_die.c