From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33928-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 5090 invoked by alias); 8 Dec 2014 10:01:13 -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: 33928
Received: (qmail 6735 invoked from network); 8 Dec 2014 10:01:11 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f5-b7fc86d0000066b7-b6-548576e3a322
Date: Mon, 08 Dec 2014 10:01:04 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Interrupting globs (Re: Something rotten in tar completion)
Message-id: <20141208100104.2949189e@pwslap01u.europe.root.pri>
In-reply-to: <141207115828.ZM23468@torch.brasslantern.com>
References: <201412071859.sB7Ix5Xq005917@pws-pc.ntlworld.com>
 <141207115828.ZM23468@torch.brasslantern.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsVy+t/xy7qPy1pDDN681rY42PyQyYHRY9XB
	D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw
	cA5wD1bSt0twy5h9eipbwSy2ip4Tc1kaGF+ydDFyckgImEhcXraMCcIWk7hwbz1bFyMXh5DA
	UkaJZz/6WCGcJUwSzecfsUA42xglrp9YBdbOIqAqMXnKGXYQm03AUGLqptmMILaIgJbEjpMn
	wcYKC3hIHNjyB6yeV8Be4ui8NcwgNqeAlcT5ubuB1nEADc2VOLC4ACTML6AvcfXvJ6iL7CVm
	XjnDCNEqKPFj8j2wMcxA4zdva2KFsOUlNq95CzZSSEBd4sbd3ewTGIVmIWmZhaRlFpKWBYzM
	qxhFU0uTC4qT0nON9IoTc4tL89L1kvNzNzFCouXrDsalx6wOMQpwMCrx8G4obw4RYk0sK67M
	PcQowcGsJMKbGNcaIsSbklhZlVqUH19UmpNafIgxGRgwE5mlRJPzgZGcVxJvaGJobmloZGxh
	YW5kRJqwkjhv5deWECGB9MSS1OzU1ILUIpgtTBycUg2MSpki/huYrPkmxPE3rOdb6OHc56L0
	jf3W6RWr2G8mHulZupOJ73oDV5cND7viQ2fFEwmz5jSLJf1Xbhew3h43++WDa4WuLU92W08Q
	UVWb9b1i9zq74FOKGqW5OW685Y/Yul74ls4MKc/i5TJ/sEPnvNdRAaPKy2dOL/1vbW+0eMdj
	/r4NgjxKLMUZiYZazEXFiQAGjzAK2gIAAA==
X-MTR: 20000000000000000@CPGS

On Sun, 7 Dec 2014 11:58:28 -0800
art Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 7,  6:59pm, Peter Stephenson wrote:
> }
> } I'm worried about the various occurrences of this:
> } 
> } 	    /* Keep any user interrupt error status */
> } 	    errflag = oef | (errflag & ERRFLAG_INT);
> 
> I believe that could be rewritten as
> 
> 	errflag &= ~ERRFLAG_ERROR;
> 	errflag |= oef;
> 
> to avoid reading errflag and then writing back to it.  That's likely
> more efficient than queueing/unqueing signals.

That's better but I think you can still get an ERRFLAG_INT missed
between reading errflag, "and"ing it with ~ERRFLAG_ERROR, and writing it
back again.  It depends on the instruction set whether that's atomic but
there's no guarantee either there or in C.

pws