Re: Freeing struct lock_file?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx> 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..


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]