From: Junio C Hamano <gitster@pobox.com>
To: "Stephen R. van den Berg" <srb@cuci.nl>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/3] git-daemon: make the signal handler almost a no-op
Date: Wed, 13 Aug 2008 18:09:43 -0700 [thread overview]
Message-ID: <7v63q4ieqw.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080814001858.GB14939@cuci.nl> (Stephen R. van den Berg's message of "Thu, 14 Aug 2008 02:18:58 +0200")
"Stephen R. van den Berg" <srb@cuci.nl> writes:
>>> @@ -1036,10 +1034,7 @@ int main(int argc, char **argv)
>>> gid_t gid = 0;
>>> int i;
>
>>> - /* Without this we cannot rely on waitpid() to tell
>>> - * what happened to our children.
>>> - */
>>> - signal(SIGCHLD, SIG_DFL);
>>> + child_handler(0);
>
>>Why?
>
> child_handler() now does barely more than setup the signal handler,
> which is exactly what we want to do here.
>
>>With your change, the first part happens to be almost no-op, but I do not
>>think it justifies this hunk.
>
>>After all, we might even want to do something like:
>
>> static void child_handler(int signo)
>> {
>> if (USE_SYSV_SIGNAL_SEMANTICS)
>> signal(SIGCHLD, child_handler);
>
>>and have the compiler optimize out the signal rearming with
>
>> cc CFLAGS=-DUSE_SYSV_SIGNAL_SEMANTICS=0
>
> In return I ask: why?
Please read the part you omitted from your quote again.
I agree it would be very meaningless change as an optimization, but I am
concerned more about robustness and what makes sense.
Do you agree that "child_handler()" is a signal handler to handle SIGCHLD,
and such a signal handler conceptually consists of two parts? i.e.
static void child_handler()
{
reap_dead_children();
rearm_signal_as_needed();
}
Your argument is it is Ok to call this function when you are arming the
signal for the first time, because reap_dead_children() happens to be
empty, and your rearm_signal_as_needed() happens to be the same as
arm_signal_always().
Yes, it happens to be _Ok_ now. But is it an improvement in the longer
term? I do not think so.
I do not see why you think it is better to rely on these two assumptions
than being explicit and say "we set up the signal for the first time
always on any platform", especially when the latter is much more direct
way to say what your intention is. Or are you gaining something by not
explicitly calling signal() for the first time? I may be missing some
benefit for doing so.
It is a trade-off between that some benefit I am not seeing, and downside
that your version can be broken more easily by future changes to
child_handler(), because you are assuming more about what it happens to do
currently.
That's the kind of thing maintainers worry more about.
next prev parent reply other threads:[~2008-08-14 1:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 8:43 [PATCH 1/3] git-daemon: logging done right Stephen R. van den Berg
2008-08-13 8:43 ` [PATCH 2/3] git-daemon: make the signal handler almost a no-op Stephen R. van den Berg
2008-08-14 0:09 ` Junio C Hamano
2008-08-14 0:18 ` Stephen R. van den Berg
2008-08-14 1:09 ` Junio C Hamano [this message]
2008-08-14 7:47 ` Stephen R. van den Berg
2008-08-14 8:26 ` Junio C Hamano
2008-08-14 10:13 ` Stephen R. van den Berg
2008-08-14 13:41 ` Johannes Schindelin
2008-08-13 8:43 ` [PATCH 3/3] git-daemon: rewrite kindergarden Stephen R. van den Berg
2008-08-13 8:58 ` Stephen R. van den Berg
2008-08-13 9:00 ` [PATCH] " Stephen R. van den Berg
2008-08-13 10:40 ` [PATCH] git-daemon: rewrite kindergarden, new option --max-connections Stephen R. van den Berg
2008-08-13 9:05 ` [PATCH 3/3] git-daemon: rewrite kindergarden Petr Baudis
2008-08-13 10:37 ` Stephen R. van den Berg
2008-08-13 23:13 ` [PATCH 1/3] git-daemon: logging done right Junio C Hamano
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=7v63q4ieqw.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=srb@cuci.nl \
/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).