From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] diff: fix textconv error zombies
Date: Wed, 31 Mar 2010 00:17:24 +0200 [thread overview]
Message-ID: <201003310017.24979.j6t@kdbg.org> (raw)
In-Reply-To: <7vk4stv5y5.fsf@alter.siamese.dyndns.org>
On Dienstag, 30. März 2010, Junio C Hamano wrote:
> In "if necessary; see below", I tried to find something to help me judge
> why you said "That's really not _that_ important in this case", but I
> think I failed. Perhaps we would want a bit more detailed discussion in
> the document there?
The "if necessary; see below" refers to the cases where the caller requests a
file descriptor from start_command(). It is safe to follow the recipe. But I
actually would not want to expand on the special case like we have in
run_textconv, where it is not strictly necessary to close the fd before
finish_command(), namely when we know that the writer will exit after it has
closed its end of the pipe and the reader reads until EOF.
This could deadlock in the theoretical case that the read() in the parent
returns an error even though the child is still writing data; the child would
hang while waiting for the pipe being drained by the parent; but the parent
would wait for the child to exit, which never happens. Doing the close()
before finish_command() avoids this situation because the child dies of
SIGPIPE.
But since the communication is via a pipe, and read failures are highly
unlikely (and a read failure in a way that the writer does not fail, too, is
even more unlikely, I think), the close() before finish_command() is "not
important".
-- Hannes
next prev parent reply other threads:[~2010-03-30 22:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-28 14:53 [PATCH 0/3] fast textconv Jeff King
2010-03-28 14:53 ` [PATCH 1/3] textconv: refactor calls to run_textconv Jeff King
2010-03-28 14:53 ` [PATCH 2/3] textconv: refactor to handle multiple textconv types Jeff King
2010-03-28 14:54 ` [PATCH 3/3] diff: add "fasttextconv" config option Jeff King
2010-03-28 18:23 ` Johannes Sixt
2010-03-30 16:30 ` Jeff King
2010-03-30 17:36 ` [PATCH] diff: fix textconv error zombies Johannes Sixt
2010-03-30 21:46 ` Junio C Hamano
2010-03-30 22:17 ` Johannes Sixt [this message]
2010-03-30 22:56 ` Jeff King
2010-03-28 16:09 ` [PATCH 0/3] fast textconv Michael J Gruber
2010-03-28 16:17 ` Jeff King
2010-03-28 16:19 ` Jeff King
2010-03-28 16:56 ` Jeff King
2010-03-28 17:34 ` Jeff King
2010-03-28 18:13 ` Sverre Rabbelier
2010-03-30 16:04 ` Jeff King
2010-03-30 3:52 ` Junio C Hamano
2010-03-30 17:07 ` 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=201003310017.24979.j6t@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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).