Re: Only store revealed pids in bgpids data structure

[John Fremlin]

On 4/15/15, 6:35 PM, "Chet Ramey" <chet.ramey@case.edu> wrote:

>On 4/14/15 12:54 AM, John Fremlin wrote:
>> Bash instances running in loops get slower over time, as the bgpids data
>> structure grows. Here is a small patch to alleviate one issue :)
>> 
>> The jobs.c:bgpids data structure is used as a cache for the wait syscall,
>> to store the status of dead processes, so that scripts can wait on pids
>> even multiple times (a bash extension not in POSIX that only allows it once).
>
>Well, and the fact that Posix says the shell is required to remember the
>status of the last CHILD_MAX async jobs (though you're right that Posix
>says the shell only has to keep track of the statuses until they are
>requested and the bash behavior is an extension).

Yes, http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html 
says

  The implementation need not retain more than the {CHILD_MAX} most recent 
entries in its list of known process IDs in the current shell execution 
environment.

And glibc says 

 
  CHILD_MAX

   If defined, the unvarying maximum number of processes that can exist with 
the same real user ID at any one time. In BSD and GNU, this is controlled by 
the RLIMIT_NPROC resource limit; see section Limiting Resource Usage 
<ftp://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_node/libc_438.html#SEC447>.


On some big production systems this can be very large (>100k) hence the need 
for the second patch.

The other side of the coin is that some systems have this limit set very small. 
That makes the facility quite unusable (as many processes are created by bash) 
so the second patch also elevates the minimum.

>
>> Some pids cannot ever be waited for in this way because they run in the
>> foreground and there is no way to see their process id.
>
>Thanks for the patch, I will install it and we will see how well it does.

Please let me know! Sorry for using Outlook