From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7454 invoked by alias); 2 Jan 2012 19:07:31 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30076 Received: (qmail 25274 invoked from network); 2 Jan 2012 19:07:20 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120102110704.ZM10434@torch.brasslantern.com> Date: Mon, 02 Jan 2012 11:07:04 -0800 In-reply-to: <120101120852.ZM12005@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: zsh-4.3.1[45] problem on FreeBSD" (Jan 1, 12:08pm) References: <1324929718.26691.140661016136941@webmail.messagingengine.com> <111226183140.ZM23495@torch.brasslantern.com> <877h1hn40t.wl%hskuhra@fastmail.fm> <87d3b3v6sn.wl%hskuhra@fastmail.fm> <120101120852.ZM12005@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: zsh-4.3.1[45] problem on FreeBSD MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 1, 12:08pm, Bart Schaefer wrote: } } I wonder if we should just queue_signals()/unqueue_signals() around } the entire body of zrefresh(), always? Or is this the only place } that's important? As Herbert has now confirmed that the race can be resolved -- Although it probably wouldn't hurt anything to queue signals around the bulk of zrefresh(), this part of zleread() is the only point at which zleactive can be true before at least one call to zrefresh() has completed; which, I think, means this is the only place where a SIGWINCH could cause confusion. I'd still like to know more about exactly what goes on under FreeBSD in the case where it hangs, but I think the conservative approach is to restrict the signal queuing to this one section. I'll add a few lines of comment and commit the patch. Adding a further queue/unqueue inside zrefresh() later won't conflict, should we find another such race condition.