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: Tue, 14 Nov 2017 07:24:31 -0800 Organization: UCLA Computer Science Department Message-ID: <21237e45-a353-92f9-01ec-7b51640d2031@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> 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 1510673135 7597 195.159.176.226 (14 Nov 2017 15:25:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Nov 2017 15:25:35 +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 Tue Nov 14 16:25:31 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 1eEd5d-0001jo-PO for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2017 16:25:29 +0100 Original-Received: from localhost ([::1]:60333 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEd5l-00077V-0z for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2017 10:25:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEd4o-00075s-Iq for emacs-devel@gnu.org; Tue, 14 Nov 2017 10:24:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEd4n-0008Fm-Kh for emacs-devel@gnu.org; Tue, 14 Nov 2017 10:24:38 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:53282) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEd4j-0008Bz-R0; Tue, 14 Nov 2017 10:24:33 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 31CD6160F9F; Tue, 14 Nov 2017 07:24:32 -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 gjaYouM0WwBS; Tue, 14 Nov 2017 07:24:31 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6F0E71610DB; Tue, 14 Nov 2017 07:24:31 -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 6M49RcfZINOS; Tue, 14 Nov 2017 07:24:31 -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 5457A160BF0; Tue, 14 Nov 2017 07:24:31 -0800 (PST) In-Reply-To: <56e722a6-95a4-0e42-185c-f26845d4f4bf@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:220181 Archived-At: On 11/14/2017 06:58 AM, Matthias Dahl wrote: > If during an active > call to wait_... all recursive calls happen to read exactly 2**32 (or > whatever bit depths EMACS_UINT is) bytes back, then we will miss it > completely and stall. First, this means that the companion idea of subtracting the two counters to yield a byte count is also buggy because the byte count will be wrong for this call. This would be a bug that could happen whenever a successful recursive call occurs, which apparently is quite common. So if we stick with the current approach, we definitely should be dropping the requirement that Eli was thinking of, which says that a positive number returned by wait_reading_process_output indicates the number of bytes read for this call. Second, I don't leaving a known bug in the code, even if the bug is unlikely. Too often, these extreme cases occur anyway (e.g., due to a network attack). I'd prefer a slightly-more-complicated solution where the bug cannot occur. It can't be that hard to fix.