From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33909-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 16632 invoked by alias); 7 Dec 2014 18:18:41 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33909
Received: (qmail 11268 invoked from network); 7 Dec 2014 18:18:28 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.2
X-Originating-IP: [86.6.25.230]
X-Spam: 0
X-Authority: v=2.1 cv=S8BXwecP c=1 sm=1 tr=0 a=c0CwWhpM9oUd/BnC3z6Gzg==:117
 a=c0CwWhpM9oUd/BnC3z6Gzg==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10
 a=BrDiTsk0AAAA:8 a=5GnKdwEaBeH3wHcTAEYA:9 a=CjuIK1q_8ugA:10
Date: Sun, 7 Dec 2014 18:18:24 +0000
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: "Zsh Hackers' List" <zsh-workers@zsh.org>
Subject: Re: Interrupting globs (Re: Something rotten in tar completion)
Message-ID: <20141207181824.6e2faf1a@pws-pc.ntlworld.com>
In-Reply-To: <17351.1417973853@thecus.kiddle.eu>
References: <20141202155452.647182b4@pwslap01u.europe.root.pri>
	<141202084858.ZM31517@torch.brasslantern.com>
	<20141202172654.30e7d380@pwslap01u.europe.root.pri>
	<141204085606.ZM9146@torch.brasslantern.com>
	<20141204171226.301e9d2c@pwslap01u.europe.root.pri>
	<141205002023.ZM19736@torch.brasslantern.com>
	<20141205145054.655a2f70@pwslap01u.europe.root.pri>
	<141205100632.ZM508@torch.brasslantern.com>
	<20141205181330.2b458b46@pwslap01u.europe.root.pri>
	<20141205203417.2bc66b7b@pws-pc.ntlworld.com>
	<20141205220717.2f86bdd2@pws-pc.ntlworld.com>
	<141206211828.ZM15934@torch.brasslantern.com>
	<20141207170713.1a71fe0d@pws-pc.ntlworld.com>
	<17351.1417973853@thecus.kiddle.eu>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sun, 07 Dec 2014 18:37:33 +0100
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Peter wrote:
> > 
> > It's also just occurred to me I may have introduced some rare but
> > entirely possible read-modify-write races because we set the ERRFLAG_INT
> > bit in interrupts and set the other and clear both bits separately in
> > the main shell.  I guess it would be better to queue interrupts whenever
> > we add or remove a single bit of errflag; that's probably not often
> > enough to cause efficiency issues since should only be round significant
> > chunks of shell code, or when an error has actually occurred.  Opinions?
> 
> Could that perhaps be solved by making errflag a volatile sig_atomic_t
> instead of an int?

It should probably at least be volatile anyway, given it's set in
interrupts regardless of the interrupt_abort changes.

It's not clear to me this is good enough to fix read/modify/write races;
as far as I can see the intention is this makes reads and writes
separately atomic.  However, I'm not an expert on this so I may be
wrong.

pws