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