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: Mon, 13 Nov 2017 11:44:43 -0800 Organization: UCLA Computer Science Department Message-ID: 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> 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 1510602299 19345 195.159.176.226 (13 Nov 2017 19:44:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 19:44:59 +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 Mon Nov 13 20:44:55 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 1eEKf6-0004hV-6T for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 20:44:52 +0100 Original-Received: from localhost ([::1]:56116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKfD-0003qC-HS for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 14:44:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKf5-0003p3-Ha for emacs-devel@gnu.org; Mon, 13 Nov 2017 14:44:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEKf4-0002kd-Cw for emacs-devel@gnu.org; Mon, 13 Nov 2017 14:44:51 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42824) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEKey-0002fg-V0; Mon, 13 Nov 2017 14:44:45 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 119F816113A; Mon, 13 Nov 2017 11:44:44 -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 UXRkd811nKhL; Mon, 13 Nov 2017 11:44:43 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4807B161132; Mon, 13 Nov 2017 11:44:43 -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 F4CF5giScRGC; Mon, 13 Nov 2017 11:44:43 -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 2D7E816112C; Mon, 13 Nov 2017 11:44:43 -0800 (PST) In-Reply-To: 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:220156 Archived-At: On 11/13/2017 06:13 AM, Matthias Dahl wrote: >> This is overkill, as the total amount of bytes read by a call to >> read_process_output cannot exceed 4096, so all we need is an unsigned >> counter with more than 12 bits. How about making it 'unsigned int' >> instead? It could even be 'unsigned short', though that might be >> overkill. Whatever size is chosen, the comment should say that the value >> recorded is the true value modulo the word size. > That would not be enough. The counter is for the entire process lifetime > and not just for a single read back or chain of recursive read backs. It cannot be for the entire process lifetime, since it's an unsigned integer that is designed to wrap around on overflow. So it sounds like you want a counter modulo 2**N for the entire process lifetime, and we're discussing what value of N is large enough for the purposes of wait_reading_process_output. Since EMACS_UINT might be only 32 bits, and it's eminently reasonable for a process to read more than 2**32 bytes during its lifetime, this is not a theoretical issue. So: why must the counter contain more than a small number of bits (16, say)? I'm not seeing the scenario. I'm asking not because I think it's important to save a few bits in the counter: I'm asking because I want to understand the change and the reasoning behind it, so that I can be sure it's fixing the bug.