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

On Mon, Apr 25, 2016 at 9:50 AM, Eric Sunshine wrote: >> @@ -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

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

Christian Couder writes: >> I do not think you need to think about "free"ing. > > Yeah, lockfile.h says: > ... > and: > ... Yup, we are now on the same page. >> Even if the libified version of the apply internal can be called >> multiple times to process multiple

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

On Mon, Apr 25, 2016 at 7:55 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> + /* >>> +* Since lockfile.c keeps a linked list of all created >>> +* lock_file structures, it isn't safe to free(lock_file). >>> +*/

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

Eric Sunshine writes: >> + /* >> +* 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

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

On Sun, Apr 24, 2016 at 9:33 AM, Christian Couder 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

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

We cannot have a 'struct lock_file' allocated on the stack, as lockfile.c keeps a linked list of all created lock_file structures. 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