Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160309073746.ZM10382@torch.brasslantern.com>
Date: Wed, 9 Mar 2016 07:37:46 -0800
In-Reply-To: <20160309095506.305d64c8@pwslap01u.europe.root.pri>
Comments: In reply to Peter Stephenson <p.stephenson@samsung.com>
        "Re: Signal handling bugaboo in command substitution" (Mar  9,  9:55am)
References: <160307184406.ZM23121@torch.brasslantern.com> 
	<20160308100004.3011d110@pwslap01u.europe.root.pri> 
	<20160308101221.625cef45@pwslap01u.europe.root.pri> 
	<CAH+w=7YCFciaFG8xMFqAefj2pK2ODkwWRM=2kiA+oGDQcxaB7Q@mail.gmail.com> 
	<20160309095506.305d64c8@pwslap01u.europe.root.pri>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Signal handling bugaboo in command substitution
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Mar 9,  9:55am, Peter Stephenson wrote:
}
} It occurs to me there's probably still a very thin race associated with
} forking and then calling entersubsh() that may be wider than just this
} case.  We'd need to queue signals before the fork and unqueue them in
} both parent and child at the end of entersubsh().  It might well be more
} trouble than it's worth to fix.

It'd also be wrong -- we don't want both the parent and the child to
handle any queued signal; in the child we'd have to erase the queue,
not just turn off queuing.

There are probably cases where this already could happen if the timing
were right.

Unless somebody comes up with a reproducible (even irregularly so) example,
I think you're right that it's more trouble than worth.