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 <dtur...@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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
