Re: Freeing struct lock_file?

[David Turner <dturner@twopensource.com>]

On Sat, 2015-04-04 at 09:16 +0200, Torsten Bögershausen wrote:
> On 2015-04-04 02.24, David Turner wrote:
> > On Fri, 2015-04-03 at 15:01 -0700, Junio C Hamano wrote:
> >> David Turner <dturner@twopensource.com> writes:
> >>
> >>> Why is it impossible to free struct lock_files?  I understand that they
> >>> become part of a linked list, and that there's an atexit handler that
> >>> goes over that list.  But couldn't we just remove them from the linked
> >>> list and then free them? 
> >>
> >> I suspect that the code is worried about getting a signal, while it
> >> is manipulating the linked list, and then cause the atexit handler
> >> to walk a list that is in a broken state.
> > 
> > This is technically possible, but practically unlikely: aligned
> > pointer-sized writes are atomic on very nearly every processor, and that
> > is all that is required to remove an item from a linked list safely in
> > this case (though not, of course, in the general multi-threaded case).
> > 
> > But I can see why git wouldn't want to depend on that behavior. C11 has
> > a way to do this safely, but AIUI, git doesn't want to move to C99 let
> > alone C11.  So I guess this will just have to remain the way it is.
> > 
> If you insist on using C11, may be.
> 
> But if there is an implementation that is #ifdef'ed and only enabled for
> "known to work processors" and a no-op for the others, why not ?
> 
> Do you have anything in special in mind ?
> A "git diff" may be a start for a patch series..

I haven't written any code for this yet.  I wanted to understand the
current code first.

My major worry is be that the code would be somewhat fragile as it
depends on not just the processor, but also the C compiler's structure
packing rules, which are implementation-dependent.  In practice, major
compilers' rules are safe, but it's annoying to have to depend on
(especially since any bugs would be incredibly difficult to reproduce).