From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches) Date: Thu, 16 Nov 2017 08:46:00 -0800 Organization: UCLA Computer Science Department Message-ID: <206ebefa-7583-f049-140c-c8fd041b0719@cs.ucla.edu> References: <83lgjz8eiy.fsf@gnu.org> <831slp98ut.fsf@gnu.org> <83tvyj62qg.fsf@gnu.org> <83r2tetf90.fsf@gnu.org> <5150d198-8dd3-9cf4-5914-b7e945294452@binary-island.eu> <83tvy7s6wi.fsf@gnu.org> <83inemrqid.fsf@gnu.org> <398f8d17-b727-d5d6-4a31-772448c7ca0d@binary-island.eu> <56e722a6-95a4-0e42-185c-f26845d4f4bf@binary-island.eu> <21237e45-a353-92f9-01ec-7b51640d2031@cs.ucla.edu> <83vaickfu2.fsf@gnu.org> <83tvxwkexg.fsf@gnu.org> <03261534-6bf5-1a5d-915f-d3c55aaa35e9@binary-island.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1510850869 10557 195.159.176.226 (16 Nov 2017 16:47:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Nov 2017 16:47:49 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: emacs-devel@gnu.org To: Matthias Dahl , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 16 17:47:46 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFNKG-0002HB-HW for ged-emacs-devel@m.gmane.org; Thu, 16 Nov 2017 17:47:40 +0100 Original-Received: from localhost ([::1]:41757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFNKN-0003xv-Mg for ged-emacs-devel@m.gmane.org; Thu, 16 Nov 2017 11:47:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFNIn-0002kv-Sy for emacs-devel@gnu.org; Thu, 16 Nov 2017 11:46:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFNIn-0005PA-3x for emacs-devel@gnu.org; Thu, 16 Nov 2017 11:46:09 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54558) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eFNIi-0005IC-Ky; Thu, 16 Nov 2017 11:46:04 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E4A94160CE5; Thu, 16 Nov 2017 08:46:01 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dGN0H8AjskBg; Thu, 16 Nov 2017 08:46:01 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 34DE7160F8D; Thu, 16 Nov 2017 08:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b_-h3GijUij8; Thu, 16 Nov 2017 08:46:01 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1C0451605A2; Thu, 16 Nov 2017 08:46:01 -0800 (PST) In-Reply-To: <03261534-6bf5-1a5d-915f-d3c55aaa35e9@binary-island.eu> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220227 Archived-At: On 11/15/2017 06:03 AM, Matthias Dahl wrote: > The crucial part is: ALL data has been read from our wait_proc while we > were running timers or filters -- and no further data will become > available until there is some interaction again with the process. Sure, but how do we know that the data read while running timers and filters was being read on behalf of our caller? Perhaps a timer or filter fired off some Elisp function that decided to read data for its own purposes, unrelated to our caller. We wouldn't want to count the data read by that function as being data of interest to our caller. In your ispell case we know that the timers and filters are reading on ispell's behalf, so the proposed fix should be OK. (If memory serves, integer overflow isn't possible for ispell either.) But I don't yet see how the fix works in general.