Re: Patch(?): bash-2.05/jobs.c loses interrupts

[Pavel Machek <pavel@suse.cz>]

Hi!

> > 	Linux-2.4.4 has a change, for which I must accept blame,
> > where fork() runs the child first, reducing unnecessary copy-on-write
> > page duplications, because the child will usually promptly do an
> > exec().  I understand this is pretty standard in most unixes.
> > 
> > 	Peter Osterlund noticed an annoying side effect of this,
> > which I think is a bash bug.  He wrote:
> > 
> > > Another thing is that the bash loop "while true ; do /bin/true ; done" is
> > > not possible to interrupt with ctrl-c.
> > 
> > 	I have reproduced this problem on a single CPU system.
> > I also modified my kernel to sometimes run the fork child first
> > and sometimes not.  In that case, that loop would sometimes
> > abort on a control-C and sometimes ignore it, but ignoring it
> > would not make the loop less likely to abort on another control-C.
> > I'm pretty sure the control-C was being delivered only to the child
> > due to a race condition in bash, which may be mandated by posix.
> 
> Did you reconfigure and rebuild bash on your machine running the 2.4
> kernel, or just use a bash binary built on a previous kernel
> version?

This is nasty race condition. I do not believe you can test for it in
configure. 

This might happen on 2.4.3 (occasionally) too. Kernel is permitted to
do any kind of scheduling!

								Pavel

> Bash has an autoconf test that will, if it detects the need to do so,
> force the job control code to synchronize between parent and child
> when setting up the process group for a new pipeline.  It may be the
> case that you have to reconfigure and rebuild bash to enable that code.
> 
> Look for PGRP_PIPE in config.h.


-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org