[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AIX and Interix also do early PID recycling.

From: Roman Rakus
Subject: Re: AIX and Interix also do early PID recycling.
Date: Tue, 28 Aug 2012 09:21:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

On 08/01/2012 03:13 PM, Chet Ramey wrote:
On 7/30/12 10:41 AM, Roman Rakus wrote:

Hmm... I don't know much about boundaries of maximum number of user
processes. But anyway - do you think that (re)changing js.c_childmax (when
`ulimit -u' is changed) is not good?
Maybe it's ok up to some fixed upper bound.  But if you're going to have
that fixed upper bound, why not just use it as the number of job exit
statuses to remember all the time?

I prepared a patch which add configure option to enable and set the number of job exit statuses to remember. I found that posix is talking about changing system configurable variables and values; quoting:
This runtime facility is not meant to provide ever-changing values that applications have to check multiple times. The values are seen as changing no more frequently than once per system initialization, such as by a system administrator or operator with an automatic configuration program. This volume of POSIX.1-2008 specifies that they shall not change within the lifetime of the process.
(see http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html)
So I would tell that bash does not need to check every time maxchild value.
However, when the maxchild is set to unlimited, now the bash will use predefined DEFAULT_CHILD_MAX which is set to 32. The attached patch adds ability to set forced number of remembered statuses, easily during configure time, example:
 ./configure --enable-fixedjsmax=2048
It will force bash to remember 2048 statuses, independently on childmax value.
Patch should clearly apply to git master branch.
Chet, what do you think about it?


Attachment: 0001-Option-to-use-fixed-number-of-remembered-job-exit-st.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]