From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-32417-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 28433 invoked by alias); 20 Feb 2014 19:36:44 -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: 32417
Received: (qmail 20000 invoked from network); 20 Feb 2014 19:36:30 -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=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=FgDGWx3lcFrAUhQPCwh4OPgl52/1yXxYpr+XvlnXsG0=;
        b=k73JDMyeCiAB44XvcRYk6sNyZVrFDo7SLvL9RaGBsO3eUeFUFB54/yx6IpYS4Zkl7h
         xZyt74XQmcq/oaw8CmU47XduVDvApWvIg4bP3kb63JxXalsSD3M0KhFFeod25DJZhxK2
         CBTe69cad/S88ngR6JEhi1Xf4TQNHquWjdDyjMUdZRCxwydpjS2Y/vvhaTPB6Pw9Z0og
         nCCVdHHVvZ6Btyets7xcuhE1Dy17+wwhre/qo2iZusHvbTADLX4Vd/GMCCqJkYstk2eo
         WXfEylx8OcgMwU2fc5bv9IZxUl2U0IrAcGuP3qQpkJ6qDaNE46/IjfrecIZZUH989DqX
         Nm7w==
X-Gm-Message-State: ALoCoQmI4v1eQekMFTyVFxQvehei4St8h2jO3whoOmcVu2Fm3GigPq0jc7umrje/QDe3eX4VW4WM
MIME-Version: 1.0
X-Received: by 10.152.43.47 with SMTP id t15mr2182605lal.38.1392924986152;
 Thu, 20 Feb 2014 11:36:26 -0800 (PST)
In-Reply-To: <20140220131659.GA21182@lilyforest>
References: <20140220050415.GA29027@lilyforest>
	<CAH+w=7Z+R_ZexSkesp2z+ndooHStOGJcMeWXtD7HCunjqJp9-Q@mail.gmail.com>
	<20140220094053.137da74f@pwslap01u.europe.root.pri>
	<20140220131659.GA21182@lilyforest>
Date: Thu, 20 Feb 2014 11:36:26 -0800
Message-ID: <CAH+w=7ZQ3ivj3DOe0e4z7_w=Av-FvLxfxzdb3vtWQpzvhCmoLw@mail.gmail.com>
Subject: It seems that I find a zle -F full CPU bug
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Cc: "lilydjwg@gmail.com" <lilydjwg@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c24100ffa7d904f2db9e3a

--001a11c24100ffa7d904f2db9e3a
Content-Type: text/plain; charset=ISO-8859-1

[ > workers ]

On Thursday, February 20, 2014, lilydjwg <lilydjwg@gmail.com> wrote:

> On Thu, Feb 20, 2014 at 09:40:53AM +0000, Peter Stephenson wrote:
> > On Wed, 19 Feb 2014 23:30:52 -0800
> > Bart Schaefer <schaefer@brasslantern.com> wrote:
> > >  I suppose we could drop the fd on the first POLLNVAL for the duration
> of
> > > that particular loop, but then reinstate it before restarting the loop
> > > after the next user input.
> >
> > That doesn't sound a bad compromise.
>
> I think this will work. Or we can just break the loop if all we get from
> the poll result is POLLNVAL so that handlers can remove bad fds.


Hmm ... looking at the loop, there is already some provision for this.  If
poll() [or select()] returns -1, we discard all the handler FDs etc. and
repeat with just the SHTTY FD.  I wonder if the situation that code is
meant to handle is even possible.

If we're really trying to avoid pathologically bad behavior, we can't rely
on the handler to remove the descriptor.

This is going to require more #ifdef's to examine fds[] in the poll() case
and the bits in errfds in the select() case.

Aside:  Am I misreading the code, or is it the case that the (HAVE_TIO &&
sun) #ifdef branch does not support zle -F ?


> The handler can know that the fd is closed in case of 'poll': the
> handler will get an argument like 'hup' or 'nval'.


I don't think the handler ever gets anything but a file descriptor number?

--001a11c24100ffa7d904f2db9e3a--