All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Joey Hess" <joey@kitenet.net>,
	git@vger.kernel.org
Subject: Re: RLIMIT_NOFILE fallback
Date: Fri, 20 Dec 2013 15:43:51 +0100	[thread overview]
Message-ID: <52B457A7.4050901@web.de> (raw)
In-Reply-To: <20131220091232.GA9637@sigill.intra.peff.net>

On 2013-12-20 10.12, Jeff King wrote:
> On Thu, Dec 19, 2013 at 09:39:55AM -0800, Junio C Hamano wrote:
> 
>> 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

My wrong: I was carefully reading the wrong version of the patch :-(
Sorry for the noise.
/torsten

  reply	other threads:[~2013-12-20 14:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-18 17:14 RLIMIT_NOFILE fallback Joey Hess
2013-12-18 18:00 ` Junio C Hamano
2013-12-18 18:41   ` Joey Hess
2013-12-18 19:17   ` Jeff King
2013-12-18 19:50     ` Junio C Hamano
2013-12-18 20:18       ` Junio C Hamano
2013-12-18 21:28       ` Jeff King
2013-12-18 21:37         ` Junio C Hamano
2013-12-18 21:40           ` Jeff King
2013-12-18 22:59             ` Junio C Hamano
2013-12-19  0:15               ` Jeff King
2013-12-19 17:30                 ` Torsten Bögershausen
2013-12-19 17:39                   ` Junio C Hamano
2013-12-20  9:12                     ` Jeff King
2013-12-20 14:43                       ` Torsten Bögershausen [this message]
2013-12-18 20:03     ` Joey Hess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B457A7.4050901@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=joey@kitenet.net \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.