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:42:50 -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> <83bmk6n9hs.fsf@gnu.org> <83y3nakw2f.fsf@gnu.org> 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 1510602193 32133 195.159.176.226 (13 Nov 2017 19:43:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 19:43:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: ml_emacs-lists@binary-island.eu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 13 20:43:10 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 1eEKdP-000805-5K for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 20:43:07 +0100 Original-Received: from localhost ([::1]:56108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKdW-0002d9-Gz for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2017 14:43:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEKdH-0002YN-QW for emacs-devel@gnu.org; Mon, 13 Nov 2017 14:43:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEKdH-0001ec-1i for emacs-devel@gnu.org; Mon, 13 Nov 2017 14:42:59 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42298) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eEKdB-0001ba-Lb; Mon, 13 Nov 2017 14:42:53 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C798416109A; Mon, 13 Nov 2017 11:42:51 -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 AcGmk3n8D5Gg; Mon, 13 Nov 2017 11:42:51 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1CD5D161102; Mon, 13 Nov 2017 11:42:51 -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 CrRZ15kAl_Xm; Mon, 13 Nov 2017 11:42:51 -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 F3819161072; Mon, 13 Nov 2017 11:42:50 -0800 (PST) In-Reply-To: <83y3nakw2f.fsf@gnu.org> 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:220155 Archived-At: On 11/13/2017 08:00 AM, Eli Zaretskii wrote: > I see no reason to consider > our commentary the definitive documentation of what the code does. It > is much more probable that either the commentary was never accurate, > or it was once, but the code was modified without updating the > comments. Hmm, well, since I wrote some of that commentary and code, I can state that it was my understanding that the caller should not care about the exact value of wait_reading_process_output's result (only whether it is negative, zero, or positive), and that my understanding of this API has survived until the present day. Partly this was because I did not want to change the type of the result if we should ever increase the buffer size from 4096 to a value that might not fit in 'int'. In other words, the documentation is written the way it's written in order to give the implementation some freedom that could be useful in the future.