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

Michael Haggerty [off-list ref] writes:

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.

In codepaths where we are likely under memory pressure, the above
might help, but I have to wonder

    (1) if update-server-info and daemon fall into that category; and

    (2) if Git continues to work under such a memory pressure to
        cause even fdopen() to fail.

In other words, I do not see a reason not to do this change, but I
am not sure how much it would help us in practice.

We call fopen() from a lot more places than we call fdopen().  Do we
want to do the same, or is there a good reason why this does not
matter to callers of fopen(), and if so why doesn't the same reason
apply to callers of fdopen()?

Michael Haggerty (5):
  xfdopen(): if first attempt fails, free memory and try again
  fdopen_lock_file(): use fdopen_with_retry()
  copy_to_log(): use fdopen_with_retry()
  update_info_file(): use fdopen_with_retry()
  buffer_fdinit(): use fdopen_with_retry()

 daemon.c              |  4 ++--
 git-compat-util.h     | 11 +++++++++++
 lockfile.c            |  2 +-
 server-info.c         |  2 +-
 vcs-svn/line_buffer.c |  2 +-
 wrapper.c             | 28 +++++++++++++++++++++++++---
 6 files changed, 41 insertions(+), 8 deletions(-)