Re: slow bgp_delete

[Chet Ramey]

> > > a) decreasing size of the 'bgpids' list. Why do we need 30k entries if
> > > we don't trust that the IDs are unique? Maybe configuration or runtime
> > > option?
> > 
> > I've thought about it.  Posix only requires saving the statuses of the last
> > CHILD_MAX asynchronous pids.  The bash code has traditionally saved
> > the statues of the last `ulimit -u' processes, regardless of whether
> > they're asynchronous.  I changed the bash development version to save
> > only asynchronous jobs to the bgpids list about a month ago.
> 
> That might do the trick unless we are running tons of asynchronous
> processes.

Yes, that's the question.  I suspect that it will be enough, since just
about any script that is creating thousands of asynchronous processes
will need some mechanism to keep track of their state, and it should not
be difficult to work a call to `wait' into such a script.

> > > b) create hash map containing the IDs to decrease the search time. We
> > > still need to maintain linked list to know which PID is oldest (to be
> > > removed). The linked list might benefit from being double linked one
> > > so that we are able to remove elements without traversing it again.
> > 
> > http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00075.html
> 
> Nice, clean patch. I like the idea to _not_ delete the PIDs from the
> linked list if the PID is reused before we ran out of the circular
> buffer. I would be concerned whether storing 1 million PIDs is not too
> memory hungry though

It is a nice patch.  I hope it's not going to be necessary based on the
outcome of the above change.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/