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: Tue, 14 Nov 2017 16:05:10 +0100 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> <83tvxykvlp.fsf@gnu.org> 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 1510671932 26261 195.159.176.226 (14 Nov 2017 15:05:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Nov 2017 15:05:32 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 14 16:05:26 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 1eEcmC-0006Sq-K4 for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2017 16:05:24 +0100 Original-Received: from localhost ([::1]:60199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEcmK-0008Vu-2D for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2017 10:05:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEcm7-0008Ug-A0 for emacs-devel@gnu.org; Tue, 14 Nov 2017 10:05:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEcm1-0005d9-E0 for emacs-devel@gnu.org; Tue, 14 Nov 2017 10:05:19 -0500 Original-Received: from ud19.udmedia.de ([194.117.254.59]:49238 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 1eEcm1-0005Zh-13 for emacs-devel@gnu.org; Tue, 14 Nov 2017 10:05:13 -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=Bi SbKPzeMel9WnBsNPiV5MHpvPVrMucnhwSOiagQCgs=; b=NnGIFIL4wH3KJo/jMc rKLWA73+Zx0/r1nA6VZg463f+gwXzGh1lqy1oiElA9liSFnkh09niyO/uOVQ8Jq/ ubYDpeG95goeFPb67Rllg6e3IflaE2pQ2OOv789kdIj5tPUF4HxOyO8OxWI0om7i uHYSsktr0ngzabYKzESJQ1TLQ= Original-Received: (qmail 1031 invoked from network); 14 Nov 2017 16:05:10 +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); 14 Nov 2017 16:05:10 +0100 Openpgp: id=1E87ADA02EFE759EFC20B2D1042F47D273AA780C In-Reply-To: <83tvxykvlp.fsf@gnu.org> 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:220179 Archived-At: Hello Eli... On 13/11/17 17:10, Eli Zaretskii wrote: > We could reset the value to zero once it's consumed, in which case a > narrower type would be okay. The price is a slight complication of > the logic. That would necessarily mean we need another variable to track how many active waits we have since we can only zero the bytes read counter when no other waits are active since they depend on that value as well. This brings us back to the in-flight bytes read solution we discussed earlier in this thread. I don't see any real gain by complicating this further. It will not be any better in detecting if any read backs have been processed. And the memory saved is pretty much completely negligible except if there were a huge amount of active processes floating around -- which usually there are definitely not. OTOH, it is more complicated and thus more prone to bugs and not as easy to understand. And the metric is also not as useful... > Maybe make the comment shorter by just saying that a wrap-around could > happen there in case of overflow. Ok. I will update that with the next revision. So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu