From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Phillip Wood via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Eric Wong <e@80x24.org>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] start_command: reset disposition of all signals in child
Date: Mon, 11 Sep 2023 15:20:40 -0700 [thread overview]
Message-ID: <xmqqa5tstkqv.fsf@gitster.g> (raw)
In-Reply-To: <c64cd85f-f14c-46b7-a0d3-b8e0bfc60053@gmail.com> (Phillip Wood's message of "Mon, 11 Sep 2023 10:50:33 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> Preserve the set of ignored signals so that running git via a
> wrapper like nohup works as the user expects
OK.
> The other thing is that we have some instances where we ignore SIGPIPE
> before calling start_command() which means we're ignoring it in the
> child process as well. For example in gpg-interface.c we have
> ...
> rev-list does not check for errors when writing to stdout unless
> GIT_FLUSH is set in the environment so if parent process exits early
> rev-list will keep going until it thinks it has printed everything.
Ahh, yeah, that is bad. Thanks for pointing them out.
> I think adding a flag to struct child_process to ignore SIGPIPE in the
> parent is probably the best way to avoid problems like this.
OK. SIGPIPE is special enough that it may deserve to be singled
out. A pager reading from us quitting does not have to be "we
wanted to write more but got an error" but just "ok, if the user
does not want any more output, that is fine".
THanks.
next prev parent reply other threads:[~2023-09-12 3:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 10:05 [PATCH] start_command: reset disposition of all signals in child Phillip Wood via GitGitGadget
2023-09-08 15:42 ` Junio C Hamano
2023-09-08 15:53 ` Phillip Wood
2023-09-08 16:24 ` Junio C Hamano
2023-09-08 16:43 ` Phillip Wood
2023-09-08 17:38 ` Junio C Hamano
2023-09-11 9:50 ` Phillip Wood
2023-09-11 22:20 ` Junio C Hamano [this message]
2023-09-08 19:57 ` Eric Wong
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=xmqqa5tstkqv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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).