Re: echo interrupted by SIGCHLD from a dying coprocess

[Tomáš Trnka]

Dne So 27. března 2010 03:50:41 Chet Ramey napsal(a):
> On 3/24/10 3:30 PM, Tomáš Trnka wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -
> > DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -
> > DCONF_VENDOR='unknown' -DLOCALEDIR='/home/trnka/opt/share/locale' -
> > DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  
> > -g - O2
> > uname output: Linux a324-2 2.6.24.2 #1 SMP Wed Feb 20 12:36:17 CET 2008
> > x86_64 GNU/Linux
> > Machine Type: x86_64-unknown-linux-gnu
> > 
> > Bash Version: 4.1
> > Patch Level: 2
> > Release Status: release
> > 
> > Description:
> > I've started using coprocesses heavily and I've found a nasty problem
> > related (but not limited) to them: After the coprocess finishes its job,
> > the resultant SIGCHLD is not properly blocked by bash signal processing
> > logic and interferes with script I/O. In my case, I've been using
> > something like:
> > 
> > read var1 var2 < <( a | long | pipeline | here)
> > echo "var1=$var1"
> > echo "var2=$var2"
> > 
> > Sometimes, the SIGCHLD arrived just when one of the echos were doing
> > output and the result was:
> > echo: write error: Interrupted system call
> > As this is a bit of a race, it occurs only when the stars are right, i.e.
> > during normal usage the probability of the SIGCHLD hitting exactly the
> > echo is quite low. However, as soon as anything causes the I/O to take
> > significantly longer, the bug appears. I've been hitting quite often
> > (30%?) when running the script over SSH.
> 
> I think there's an easier way to do this.  Try the attached patch and
> see what you get.
> 
> Chet
>
> *** ../bash-4.1-patched/sig.c   Fri Aug 14 16:31:52 2009
> --- sig.c   Fri Mar 26 22:34:11 2010
> ***
> *** 655,660 
> --- 655,663 
>  act.sa_flags |= SA_INTERRUPT; /* XXX */
>else
>  act.sa_flags |= SA_RESTART;   /* XXX */
>+ #else
>+   if (sig == SIGCHLD)
>+ act.sa_flags |= SA_RESTART;
>  #endif
>sigemptyset (&act.sa_mask);
>sigemptyset (&oact.sa_mask);

Hello there,

could you please release this as an official Bash patch? It's been almost half 
a 
year and it seems not to cause any problems...
Best regards

2T


smime.p7s
Description: S/MIME cryptographic signature

RFE: automatic "time" output for long-running commands

[John Saalwaechter]

When I've used tcsh in the past, a very useful feature was its "time"
variable.  From the man page:

"""
time
Controls automatic timing of commands.  If set, then any command that
takes more than this many CPU seconds will cause a line giving user,
system, and real times, and a utilization percentage which is the
ratio of user plus system times to real time to be printed when it
terminates.
"""

This is a great convenience, because you don't need to anticipate
ahead of time which commands you want to run using the time builtin.
Any long running command automatically results in getting "time"
output, regardless of whether you anticipated the long run time or
not.  In fact, it's often the commands that unexpectedly ran long that
you want time output for.

Example showing this behavior in in tcsh:

% set time=5
% echo this is a short cmd
this is a short cmd
% ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep  7 12:04 /dev/null
% perl -e 'alarm(10); while(1){$a++}'
Alarm clock
9.9u 0.0s 0:10.00 99.4% 0+0k 0+0io 0pf+0w
%

John
--
saalwaech...@gmail.com