Re: Freeing struct lock_file?
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Apr 4, 2015, 07:16 UTC
- Message-ID
- <551F8FC3.8010104@web.de>
- In-Reply-To
- <1428107083.31333.11.camel@ubuntu>
On 2015-04-04 02.24, David Turner wrote:
Show 21 quoted lines
> 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..