Re: slow bgp_delete

[Vladimir Marek]

> > 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.



> > 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
...



> We'll see if the change to save only asynchronous pids makes enough of
> a difference.  I've attached that patch if you want to look at it; line
> numbers will certainly vary.

Thank you, I will try that.



> > c) some means to clear the 'bgpids' list during runtime.
> 
> `wait' with no arguments discards all saved status values.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wait.html#tag_20_153
> 
> `disown -a' will also work.

Ah, I missed that opportunity, good tip for a workaround.


Thank you Chet for your help
-- 
        Vlad