From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10292 invoked by alias); 20 Feb 2014 20:47:37 -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: 32419 Received: (qmail 12431 invoked from network); 20 Feb 2014 20:47:23 -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=v4s9EbsaKzP/grr9TGYMBHPq61BW5qnVPQIdYUCZflc=; b=mqAIxZuMggAPnSyZQpSwCAcbIhXs5kB7ZyjqHNuoFmqSrkWg9BR6M9joUGaCyTRS6F JHEZZnCyLLfOU6/nHKBkHW9SI46+AvbkSrux0JA0lRtlDgoL11ZO/6lpkRrtb9SK8KML n8sJX0Uh10i+c2N3ZQmwehDCVLUR4v6cyE/yI/U4AwGQ5JwAjNb1SanRkZImPsPIS2c/ bhlbbP7yBP0ogpF3Tub3vCxmqdeNrSFiWMq6p2AwZQpZaO6nW0DwKee2Rmfn1QHnoxDl KFo1StYh9OFvBv9lP/WAVn24fuDm1tUVrbzYMqQXghbXgVlHXGS1NPh5ui69LXnGUQPG XTDw== X-Gm-Message-State: ALoCoQmyli3nAuhLPombOMw/Qkdki1IVyjKKbG9uqbntd4dXgndChDQYj8D6KI+0gfCTuPH0rE3r MIME-Version: 1.0 X-Received: by 10.112.63.193 with SMTP id i1mr2202459lbs.54.1392929238402; Thu, 20 Feb 2014 12:47:18 -0800 (PST) In-Reply-To: References: <20140220050415.GA29027@lilyforest> <20140220094053.137da74f@pwslap01u.europe.root.pri> <20140220131659.GA21182@lilyforest> Date: Thu, 20 Feb 2014 12:47:18 -0800 Message-ID: Subject: Re: It seems that I find a zle -F full CPU bug From: Bart Schaefer To: Zsh hackers list Cc: "lilydjwg@gmail.com" Content-Type: multipart/alternative; boundary=001a11c3fd1073e06404f2dc9c25 --001a11c3fd1073e06404f2dc9c25 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, February 20, 2014, Bart Schaefer wrote: > > 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. > Interrupt on a signal is a case where this can happen, it appears. > Aside: Am I misreading the code, or is it the case that the (HAVE_TIO && > sun) #ifdef branch does not support zle -F ? > If there is user typeahead this branch is going to read it and return. If not then it falls through to one of poll() or select() on the other descriptors. So I this appears OK, though it may be delayed more than other cases in calling the handlers. > 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? Hmm. It appears that a widget handlers (zle -F -w) will never get anything but a descriptor number. Without -w, the handler will get either the descriptor number or a string describing the error condition (which means in order to remove itself on an error, the handler has to know out of band which descriptor it is watching?). Those error-string values are not documented. However ... and again I may be reading this wrong ... I think the outer test for whether to call the handler at all will skip the handlers for FDs with error states. In the HAVE_POLL branch, for example, it first looks for the POLLIN flags but not for any error flags? So it will never reach the set of tests that examine POLLNVAL et al.? That aside, dropping the invalid descriptors for the select() case is easy, just change the bitflags. For the poll() case it's going to be more work because the fds[] array of structs will have to be rearranged. --001a11c3fd1073e06404f2dc9c25--