Re: [PATCH] circular buffer + hash for jobs.c:bgpids

[John Fremlin]

On 4/19/15, 5:24 PM, "Chet Ramey" <chet.ramey@case.edu> wrote:

>On 4/17/15 4:55 PM, John Fremlin wrote:
>> Did some benchmarks, for the while true; do (:) & (:); done simple
>>example
>> this goes from 215 to 313 iterations/s, and changes sys+user CPU from
>>152%
>> to 45%
>> 
>> Any long running bash script will tend to exhibit this issue --
>
>I disagree that `any' long-running bash script will create thousands of
>asychronous jobs and never call `wait' with no arguments.  It's not
>clear that your example above is realistic.
>
>Let's see what happens with your patch to change bash to save statuses of
>asynchronous jobs instead of all jobs before we see whether another change
>is warranted.

It¹s true that with the first patch then this one is less important and
there will only be this long slowdown for bash sessions that have many
asynchronous processes and that do not call wait with no arguments.

However, why should there be a performance penalty of high order for using
asynchronous processes? Calling wait with no arguments breaks modularity
boundaries in that the caller of it precludes other callers within the
same bash context from using asynchronous processes in an independent way.
Independently of the real world probability of someone running while true;
do : & :; done (which we all must agree is low) this diff improves the
performance of workloads with asynchronous processes, and also improves
things by making sure we don¹t slavishly follow the CHILD_MAX limit which
can be unusably low :)