Re: [PATCH] Make xmalloc and xrealloc thread-safe

From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	Junio C Hamano <gitster@pobox.com>,
	Fredrik Kuivinen <frekui@gmail.com>,
	git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>,
	Bo Yang <struggleyb.nku@gmail.com>
Subject: Re: [PATCH] Make xmalloc and xrealloc thread-safe
Date: Wed, 24 Mar 2010 14:28:51 -0700	[thread overview]
Message-ID: <7vsk7p4df0.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20100324202814.GA24830@spearce.org> (Shawn O. Pearce's message of "Wed\, 24 Mar 2010 13\:28\:14 -0700")

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> @@ -100,7 +112,7 @@ void *xmmap(void *start, size_t length,
>>  	if (ret == MAP_FAILED) {
>>  		if (!length)
>>  			return NULL;
>> -		release_pack_memory(length, fd);
>> +		try_to_free_routine(length);
>
> This isn't dubious!  The fd passed here is to prevent the pack release
> code from closing this fd right before we try to mmap it.  Its an actual
> bug fix that I had to write years ago, check the history of that section
> of code...  :-)

A tangent.

I thought that it incidentally might be a good example for the "line-mode"
log that has been discussed recently to follow the history of this code,
but this turns out to be too easy:

$ git blame -C -L'/^void \*xmmap/,/^}/' wrapper.c

directly gives you the answer.  d1efefa4 explains why this passes fd
rather well.