[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow bgp_delete
From: |
Vladimir Marek |
Subject: |
Re: slow bgp_delete |
Date: |
Tue, 23 Jun 2015 11:13:16 +0200 |
User-agent: |
Mutt/1.5.22.1-rc1 (2013-10-16) |
Hi Chet,
...
> > 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.
> *** bash-20150410/jobs.c 2015-04-17 14:32:17.000000000 -0400
> --- bash-20150417/jobs.c 2015-04-15 21:28:08.000000000 -0400
> ***************
> *** 1044,1051 ****
> return;
>
> ! if ((dflags & DEL_NOBGPID) == 0)
> {
> proc = find_last_proc (job_index, 0);
> - /* Could do this just for J_ASYNC jobs, but we save all. */
> if (proc)
> bgp_add (proc->pid, process_exit_status (proc->status));
> --- 1044,1050 ----
> return;
>
> ! if ((dflags & DEL_NOBGPID) == 0 && (temp->flags & (J_ASYNC|J_FOREGROUND))
> == J_ASYNC)
> {
> proc = find_last_proc (job_index, 0);
> if (proc)
> bgp_add (proc->pid, process_exit_status (proc->status));
The patch works nicely. However there were internal concerns that this
change might cause some incompatibility to existing scripts. I would
like to ask for your opinion on it.
I am trying to come up with a scenario where this change might cause
existing script to break. This would be one possibility:
PID=$( echo $BASHPID; exec synchronous_command )
wait $PID
RET=$?
Before the patch in question this would return the exit status of
'synchronous_command', afther the change one would get error
bash: wait: pid 1234 is not a child of this shell
There might be other ways of passing the PID value out of the subshell,
but otherwise it's pretty much I can think of.
I would say that it is very unlikely someone would be running such a
construct (especially it is not explicitly mentioned in the man page
that synchronous jobs are being captured). But you will probably have
better idea how bash is (ab)used; how serious do you think this is?
Thank you
--
Vlad
- Re: slow bgp_delete,
Vladimir Marek <=