git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Tay Ray Chuan <rctay89@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] http: add_fill_function checks if function has been added
Date: Sat, 07 Mar 2009 12:18:02 -0800	[thread overview]
Message-ID: <7vy6vhm6it.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 49B266B0.4020304@gmail.com

Tay Ray Chuan <rctay89@gmail.com> writes:

> This patch ensures that the same fill function is called once so to
> prevent any possible issues.
>
> Nevertheless, calling a fill function repeatedly in
> ''fill_active_slots'' will not lead to any obvious change in existing
> behavior, though performance might be affected.
>
> ''add_fill_action'' checks if the function to be added has already been
> added. Allocation of memory for the list ''fill_chain*'' is postponed
> until the check passes, unlike previously.

Could you care to explain the following a bit better?

 - what "possible issues" you are addressing;

 - what changes in the behaviour that are not "obvious" we would be
   suffering from, if we apply this patch;

 - in what situation the performance _might_ be affected, in what way and
   to what extent.

If the patch author does not have clear answers to these questions, how
can others decide if it is worth reading the patch to judge if it is worth
applying?

In other words, I'd expect you to explain the issues like this:

    add_fill_function() adds the same fill function twice on the fill_cfg
    list; this causes THIS and THAT breakages when the fill function is
    called twice.

    Ignore add_fill_function() when fill_cfg list already has the function
    registered on it to fix this issue.  Note however that the new code may
    behave very inefficiently under this situation:

    - XYZZY happens, then
    - FROTZ happens, and then
    - NITFOL happens.

    In such a case we end up doing FROTZ repeatedly, and ...; we might
    want to later optimize this, but a correctly working code is more
    important than efficient code that works most of the time but silently
    breaks in some cases.

    We need to iterate over the existing entries in fill_cfg list to find
    duplicates, which may look like an overhead, but the existing function
    already needed to do so to queue the new entry at the end anyway, so
    this is nothing new.

  reply	other threads:[~2009-03-07 20:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-07 12:21 [PATCH] http: add_fill_function checks if function has been added Tay Ray Chuan
2009-03-07 20:18 ` Junio C Hamano [this message]
2009-03-07 20:49   ` Tay Ray Chuan
2009-03-07 21:49     ` Junio C Hamano
2009-03-08 10:27       ` Tay Ray Chuan
2009-03-08 19:38         ` Junio C Hamano
2009-03-09 12:01           ` Tay Ray Chuan

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=7vy6vhm6it.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=rctay89@gmail.com \
    /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).