Re: [PATCH 0/5] Retry if fdopen() fails due to ENOMEM

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 17, 2015, 22:32 UTC
Message-ID: <xmqqlhivmf0t.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54FED916.6020607@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 24 quoted lines

> On 03/06/2015 06:08 AM, Torsten Bögershausen wrote:
>> On 03/05/2015 05:07 PM, Michael Haggerty wrote:
>>> One likely reason for fdopen() to fail is the lack of memory for
>>> allocating a FILE structure. When that happens, try freeing some
>>> memory and calling fdopen() again in the hope that it will work the
>>> second time.
>>>
>>> This change was suggested by Jonathan Nieder [1]
>>>
>>> In the first patch it is unsatisfying that try_to_free_routine() is
>>> called with a magic number (1000) rather than sizeof(FILE). But the C
>>> standard doesn't guarantee that FILE is a complete type, so I can't
>>> think of a better approach. Suggestions, anybody?
>> 
>> it's not the sizeof(FILE) which is critical, it is the size of the buffer
>> associated with a FILE
>> 
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html
>> 
>> BUFSIZ may be  your friend, and if it is not defined, 4096 may be a
>> useful default.
>
> Good point. If this patch series is not dropped as being useless, I will
> make this change.

OK, it has been a week since anybody mentioned this series. What's the verdict? Taking what you said in $gmane/265228 into account, I am taking the lack of reroll or follow-up as a sign of lost interest, and if that is the case I'd drop the series before it hits 'next'.

Thanks.