git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RLIMIT_NOFILE fallback

From
Jeff King <peff@peff.net>
Date
Dec 20, 2013, 09:12 UTC
Message-ID
<20131220091232.GA9637@sigill.intra.peff.net>
In-Reply-To
<xmqqmwjwg2ok.fsf@gitster.dls.corp.google.com>
On Thu, Dec 19, 2013 at 09:39:55AM -0800, Junio C Hamano wrote:
Show 16 quoted lines
> Torsten Bögershausen <tboegi@web.de> writes:
> 
> > Thanks for an interesting reading,
> > please allow a side question:
> > Could it be, that "-1 == unlimited" is Linux specific?
> > And therefore not 100% portable ?
> >
> > And doesn't "unlimited" number of files call for trouble,
> > having the risk to starve the machine ?
> >
> > BTW: cygwin returns 256.
> 
> If you look at the caller, you will see that we do cap the value
> returned from this helper function down to a more reasonable and not
> so selfish maximum, exactly for the purpose of avoiding the risk of
> starving other processes.

I am not sure you are reading the capping in the right direction. We do not cap at 25, but rather keep 25 open for "other stuff". So at unlimited, we are consuming a mere UINT_MAX-25 descriptors. :)

I think that 25 is not for the benefit of the rest of the system, but rather for _us_ to avoid running out of descriptors for normal operations. I do not think we need to be careful about starving other processes at all. That is the job of the ulimit in the first place, and we respect it. If the sysadmin turns off the limit, then we are just following their instructions.

In practice, I'd be shocked if git behaved reasonably above about 500 packs anyway, so that puts a practical cap on our fd use. :)

None of that impacts the patch under discussion, though. The only thing I was trying to bring up earlier is that on a system with:

  1. No (or broken) getrlimit
  2. No OPEN_MAX defined
  3. sysconf that works, and returns -1 for unlimited
  4. a sysadmin who has set the descriptor limit to "unlimited"

We will end up at "1". Which is not great, but I am skeptical that a system matching the above 4 constraints actually exists. So I think the patch is fine in practice.

-Peff
Previous: Junio C HamanoNext: Torsten Bögershausen
Message 14 of 16 in “RLIMIT_NOFILE fallback”
  1. Joey HessDec 18, 2013
  2. Junio C HamanoDec 18, 2013
  3. Joey HessDec 18, 2013
  4. Jeff KingDec 18, 2013
  5. Junio C HamanoDec 18, 2013
  6. Junio C HamanoDec 18, 2013
  7. Jeff KingDec 18, 2013
  8. Junio C HamanoDec 18, 2013
  9. Jeff KingDec 18, 2013
  10. Junio C HamanoDec 18, 2013
  11. Jeff KingDec 19, 2013
  12. Torsten BögershausenDec 19, 2013
  13. Junio C HamanoDec 19, 2013
  14. Jeff KingDec 20, 2013
  15. Torsten BögershausenDec 20, 2013
  16. Joey HessDec 18, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.