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

Michael Haggerty [off-list ref] writes:

On 03/06/2015 06:08 AM, Torsten Bögershausen wrote:

quoted

On 03/05/2015 05:07 PM, Michael Haggerty wrote:

quoted

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.