From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-31338-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 25400 invoked by alias); 26 Apr 2013 18:38:22 -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: 31338
Received: (qmail 29600 invoked from network); 26 Apr 2013 18:38: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=-0.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,
	RCVD_NUMERIC_HELO,SPF_HELO_PASS autolearn=no version=3.3.2
Received-SPF: pass (ns1.primenet.com.au: SPF record at m.gmane.org designates 80.91.229.3 as permitted sender)
X-Injected-Via-Gmane: http://gmane.org/
To: zsh-workers@zsh.org
From: Yuri D'Elia <wavexx@users.sourceforge.net>
Subject: Re: precmd: write error: interrupted
Date: Fri, 26 Apr 2013 19:59:19 +0200
Message-ID: <517AC077.9080703@users.sourceforge.net>
References: <klbmnc$ieh$1@ger.gmane.org> <130425111646.ZM17258@torch.brasslantern.com>	<klc2ah$jiv$1@ger.gmane.org> <130426080805.ZM18619__18102.73175729$1366989065$gmane$org@torch.brasslantern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
Cc: zsh-users@zsh.org
X-Gmane-NNTP-Posting-Host: 193.106.183.18
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
In-Reply-To: <130426080805.ZM18619__18102.73175729$1366989065$gmane$org@torch.brasslantern.com>

On 04/26/2013 05:08 PM, Bart Schaefer wrote:
> } What other syscalls would be interrupted by SIGWINCH that shouldn't be
> } restarted? Right now I cannot think of anything that SIGWINCH should
> } interrupt.
>
> I've been thinking about this, and the problem with using SA_RESTART is
> twofold:
>
> (1) [Minor] Some platforms don't have restartable syscalls, so this won't
> work everywhere.  But perhaps the intersection of non-restarable syscalls
> and support for SIGWINCH is empty.

(I'm somehow curious of which systems don't support SIGWINCH, must be 
particularly old).

> (2) [Potentially major] A user-defined trap can be installed for the
> SIGWINCH signal.  That means arbitrary shell code might execute during
> handling of the signal, so all sorts of things might happen mid-write,
> not just the default ioctls.

I see, and now I also see your reasoning about queuing SIGWINCH 
everywhere except when waiting in zleread. At any rate, that's the only 
point where updating the terminal for the upcoming output makes sense. 
Updating the column count (for example) while in the middle of a widget 
expansion for instance won't likely help (or maybe even break some 
invariant).