All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Olga Telezhnaya <olyatelezhnaya@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH Outreachy] mru: use double-linked list from list.h
Date: Thu, 28 Sep 2017 17:04:39 -0400	[thread overview]
Message-ID: <20170928210439.msmzxlih4ykrsmee@sigill.intra.peff.net> (raw)
In-Reply-To: <0102015ec7a3424b-529be659-bdb6-42c4-a48f-db264f33d53a-000000@eu-west-1.amazonses.com>

On Thu, Sep 28, 2017 at 08:38:39AM +0000, Olga Telezhnaya wrote:

> Simplify mru.c, mru.h and related code by reusing the double-linked
> list implementation from list.h instead of a custom one.

The commit message is a good reason to talk about why we want to do
this. In this case, the answer may be fairly obvious. But I sometimes
find that things that are obvious to me as the patch author are not
quite as obvious to people reading it later (either reviewing, or six
months from now when they are hunting the cause of a bug).

> -void mru_mark(struct mru *mru, struct mru_entry *entry)
> +void mru_mark(struct mru *head, struct mru *entry)
>  {
> -	/* If we're already at the front of the list, nothing to do */
> -	if (mru->head == entry)
> -		return;
> -
> -	/* Otherwise, remove us from our current slot... */
> -	if (entry->prev)
> -		entry->prev->next = entry->next;
> -	if (entry->next)
> -		entry->next->prev = entry->prev;
> -	else
> -		mru->tail = entry->prev;
> -
> -	/* And insert us at the beginning. */
> -	entry->prev = NULL;
> -	entry->next = mru->head;
> -	if (mru->head)
> -		mru->head->prev = entry;
> -	mru->head = entry;
> +	/* To mark means to put at the front of the list. */
> +	list_del(&entry->list);
> +	list_add(&entry->list, &head->list);
>  }

Nice, this hunk is very satisfying. :)

> -void mru_clear(struct mru *mru)
> +void mru_clear(struct mru *head)
>  {
> -	struct mru_entry *p = mru->head;
> -
> -	while (p) {
> -		struct mru_entry *to_free = p;
> -		p = p->next;
> +	struct list_head *p1;
> +	struct list_head *p2;
> +	struct mru *to_free;
> +	
> +	list_for_each_safe(p1, p2, &head->list) {
> +		to_free = list_entry(p1, struct mru, list);
>  		free(to_free);
>  	}
> -	mru->head = mru->tail = NULL;
> +	INIT_LIST_HEAD(&head->list);

Two minor style comments here:

  - Perhaps "tmp" is a better name than "p2" for the second argument of
    a list_for_each_safe, as it makes it less likely to confuse p1 and
    p2 (though admittedly the whole function is short enough that it
    probably doesn't matter much either way).

  - It's a good practice to declare variables in the smallest scope
    possible. So I think the declaration of to_free could go inside the
    loop.

    You could actually get rid of it entirely with:

      free(list_entry(p1, struct mru, list));

    but I certainly don't mind using a variable for better readability.

> @@ -29,17 +28,13 @@
>   * you will begin traversing the whole list again.
>   */
>  
> -struct mru_entry {
> -	void *item;
> -	struct mru_entry *prev, *next;
> -};
> -
>  struct mru {
> -	struct mru_entry *head, *tail;
> +	struct list_head list;
> +        void *item;
>  };

The decision to get rid of the "mru versus mru_entry" distinction
surprised me a little. In the original, a "struct mru" represented the
whole list. In the list.h implementation, a "struct list_head" serves
that purpose, as a sentinel value. But that sentinel doesn't need to
have an "item", right? I.e., we could have:

  struct mru {
          struct list_head head;
  };

  struct mru_entry {
          void *item;
	  struct list_head list;
  };

As I said in my response to Junio (and as we discussed a little
off-list), I think we can eventually move to having no structs at all
(just list_heads embedded inside the existing packfile objects). At
which point the user of the API would just declare:

  LIST_HEAD(packed_git_mru);

themselves. So I'm actually fine with this direction if we're using it
as the "middle step" that I mentioned there.

>  struct mru {
> -	struct mru_entry *head, *tail;
> +	struct list_head list;
> +        void *item;
>  };

The funny indentation in this diff shows that "void *item" is indented
with spaces, not a tab.

> [...]

I pointed out a few minor bits, but overall this is looking very strong.
Great work!

-Peff

  parent reply	other threads:[~2017-09-28 21:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 10:18 [PATCH] [Outreachy] cleanup: use list.h in mru.h and mru.c Оля Тележная
2017-09-27 11:30 ` Christian Couder
2017-09-28  8:38   ` [PATCH Outreachy] mru: use double-linked list from list.h Olga Telezhnaya
2017-09-28 11:03     ` Junio C Hamano
2017-09-28 20:47       ` Jeff King
2017-09-28 21:56         ` Junio C Hamano
2017-09-28 22:19           ` Jeff King
2017-09-28 21:04     ` Jeff King [this message]
2017-09-28 22:42     ` Jeff King
2017-09-29  7:18       ` Christian Couder
2017-09-29  7:23         ` Jeff King
2017-09-29 11:50           ` Christian Couder
2017-09-29 16:08             ` Оля Тележная
2017-09-29 20:38               ` Оля Тележная
2017-09-29 23:40                 ` Jeff King
2017-09-30 18:09                   ` Оля Тележная
2017-10-02  8:22                     ` Jeff King
2017-09-29 23:37               ` Jeff King
2017-09-30  0:07                 ` Junio C Hamano
2017-09-30 17:51     ` [PATCH v2 " Olga Telezhnaya
2017-10-02  8:20       ` Jeff King
2017-10-02  9:37         ` Оля Тележная
2017-10-03 10:10           ` Jeff King
2017-11-08  1:44         ` Junio C Hamano
2017-11-08  4:22           ` Jeff King
2017-11-10 11:51             ` Оля Тележная

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=20170928210439.msmzxlih4ykrsmee@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=olyatelezhnaya@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.