From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Matthias Dahl Newsgroups: gmane.emacs.devel Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches) Date: Mon, 20 Nov 2017 16:29:38 +0100 Message-ID: References: <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> <206ebefa-7583-f049-140c-c8fd041b0719@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1511191820 12499 195.159.176.226 (20 Nov 2017 15:30:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 15:30:20 +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: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 20 16:30:13 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 1eGo1T-0002iJ-0e for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2017 16:30:11 +0100 Original-Received: from localhost ([::1]:57942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGo1a-0002UV-FG for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2017 10:30:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGo13-0002Tz-5K for emacs-devel@gnu.org; Mon, 20 Nov 2017 10:29:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGo0z-0003be-Ux for emacs-devel@gnu.org; Mon, 20 Nov 2017 10:29:45 -0500 Original-Received: from ud19.udmedia.de ([194.117.254.59]:39598 helo=mail.ud19.udmedia.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGo0z-0003aN-IZ for emacs-devel@gnu.org; Mon, 20 Nov 2017 10:29:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=binary-island.eu; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=k1; bh=Fa sGK/MkfoO+afkw6EUNfEfe05GFP2UZiIC4NRGZZbU=; b=LBb9eH4G4Uer4giyqk JaXnrXPXtkSjSE2IavCjRernUG69NIYAz6Q5JdIOJo/M0F7suyLpGtAA9kwApdFl +Db51jjHhhQkLgygYy7zwurioVp8GHWlrOM/DDcOekTLBFB7QkAE+ABBmde/7t7U JZ/CzKqy+yMTofHIDOqzOHshE= Original-Received: (qmail 14760 invoked from network); 20 Nov 2017 16:29:38 +0100 Original-Received: from unknown (HELO ?IPv6:2a02:810b:c540:234:36aa:25b9:ca8f:d05f?) (ud19?126p1@2a02:810b:c540:234:36aa:25b9:ca8f:d05f) by mail.ud19.udmedia.de with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256 encrypted, authenticated); 20 Nov 2017 16:29:38 +0100 Openpgp: id=1E87ADA02EFE759EFC20B2D1042F47D273AA780C In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 194.117.254.59 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:220292 Archived-At: Hello Paul... On 19/11/17 08:07, Paul Eggert wrote: > * Fix the bug with carryover that I mentioned in > . Done already locally, will be in the revised patch. > * Document in the Elisp manual that filters and timers are supposed to > do "proper management and synchronization", and be clear about how this > constrains filters and timers. (This is probably the hardest part of the > fix....) I believe Eli said he will take care of this one. > * Change the type of infd_num_bytes_read from EMACS_UINT to uintmax_t. > This will provide an extra margin of safety on some platforms. > infd_num_bytes_read has nothing to do with Emacs integers, and wider > counts are safer. Thanks, didn't know about that one. Will do. > * Document in its comment that infd_num_bytes_read is actually the count > modulo UINTMAX_MAX + 1. On my todo, will be on the new patch. > * When assigning to got_some_output, ceiling it at INT_MAX to avoid > overflow problems. Something like the following, say: > >    got_some_output = min (INT_MAX, (wait_proc->infd_num_bytes_read >                                     - initial_wait_proc_num_bytes_read)); Actually, I already spotted this and corrected it locally. I would have mentioned it in the revised patch. Thanks though for your keen eye. :-) > This removes the need for that long comment about overflow, since this > assignment cannot overflow. Not quite. The long comment explicitly explains why we can always do the subtraction this way because we could end up in a situation were we subtract a larger number from a smaller number, e.g. when the initial value was close to the max and once data was read, we had a wrap around. The assignment itself was another issue, that went unnoticed in the first patch. ;-) I'll update the patches tomorrow most likely and send them to the list as I just didn't get around to it today. Thanks again for all the great feedback. So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu