Re: [PATCH 49/83] builtin/apply: move 'lock_file' global into 'struct apply_state'

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Apr 25, 2016, 07:50 UTC
Message-ID: <CAPig+cRSe8oOjo2h6SuJQyD+he_Q7zHfF4TivZ0amhAu4HLQ+g@mail.gmail.com>
In-Reply-To: <1461504863-15946-50-git-send-email-chriscool@tuxfamily.org>

On Sun, Apr 24, 2016 at 9:33 AM, Christian Couder <christian.couder@gmail.com> wrote:

> We cannot have a 'struct lock_file' allocated on the stack, as lockfile.c
> keeps a linked list of all created lock_file structures.

By talking about "the stack" here, I suppose you mean that your initial idea was to move the global lock_file into cmd_apply() or something?

Show 12 quoted lines

> So let's make the 'lock_file' variable a pointer to a 'struct lock_file'
> and let's alloc the struct when needed.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> diff --git a/builtin/apply.c b/builtin/apply.c
> @@ -52,6 +52,12 @@ struct apply_state {
> +       /*
> +        * Since lockfile.c keeps a linked list of all created
> +        * lock_file structures, it isn't safe to free(lock_file).
> +        */
> +       struct lock_file *lock_file;

Is there ever a time when lock_file is removed from the list (such as upon successful write of the index), in which case it would be safe to free() this?

Show 5 quoted lines

> @@ -4515,8 +4521,6 @@ static int write_out_results(struct apply_state *state, struct patch *list)
>         return errs;
>  }
>
> -static struct lock_file lock_file;

Does the static lock_file in build_fake_ancestor() deserve the same sort of treatment? (I haven't traced the code enough to answer this.)

>  #define INACCURATE_EOF (1<<0)
>  #define RECOUNT                (1<<1)