bug-bash
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]