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: Sat, 18 Nov 2017 15:24:26 +0100 Message-ID: References: <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> <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 1511015087 1178 195.159.176.226 (18 Nov 2017 14:24:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Nov 2017 14:24:47 +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 Sat Nov 18 15:24:40 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 1eG42v-0008Bm-T0 for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 15:24:38 +0100 Original-Received: from localhost ([::1]:50212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eG432-0004Nl-Jj for ged-emacs-devel@m.gmane.org; Sat, 18 Nov 2017 09:24:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eG42w-0004NR-J3 for emacs-devel@gnu.org; Sat, 18 Nov 2017 09:24:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eG42s-0000SP-Ha for emacs-devel@gnu.org; Sat, 18 Nov 2017 09:24:38 -0500 Original-Received: from ud19.udmedia.de ([194.117.254.59]:34886 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 1eG42s-0000Ri-4f for emacs-devel@gnu.org; Sat, 18 Nov 2017 09:24:34 -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=85 ClL4mMQBpgxMsDxGWLTsC5po77xNyya8BSZE1RXDA=; b=hJZ4pDxHaTqOeImGGN w451UcXJ2urGbUL4aNbCHBa498fvsjDhhmPHIT0yq9Hu5rBMl+SChsWX5A5ia7MW cN7JU+KdPm6z61BHseWkfOtzUsHKix5EKHDY6mP+SvflDkwb6eYIwo6gGQZpPKC3 HsIBS5rSmqbs3BsWEhL/+pl6A= Original-Received: (qmail 22697 invoked from network); 18 Nov 2017 15:24:29 +0100 Original-Received: from ip5f58867b.dynamic.kabel-deutschland.de (HELO ?10.0.0.20?) (ud19?126p1@95.88.134.123) by mail.ud19.udmedia.de with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256 encrypted, authenticated); 18 Nov 2017 15:24:29 +0100 Openpgp: id=1E87ADA02EFE759EFC20B2D1042F47D273AA780C In-Reply-To: <206ebefa-7583-f049-140c-c8fd041b0719@cs.ucla.edu> 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:220262 Archived-At: Hello Paul... On 16/11/17 17:46, Paul Eggert wrote: > Sure, but how do we know that the data read while running timers and > filters was being read on behalf of our caller? Perhaps a timer or > filter fired off some Elisp function that decided to read data for its > own purposes, unrelated to our caller. We wouldn't want to count the > data read by that function as being data of interest to our caller. I had considered that when I debugged the bug but think about it for a moment. If you treat the process as a shared resource, it is your sole responsibility to take care of proper management and synchronization of the process as well. If a wait_... is in progress for process A which is the response to some interaction A* (w/ filter F1), then if the timers get processed during our wait and end up with another interaction B* (w/ filter F2) to process A that will cause havoc either way. They will probably read the data that was destined for filter F1 or things get messed up even more horribly. Thus, that should not happen. And there is actually nothing Emacs can do about it form its side. This is solely the responsibility of package authors and so forth to make sure things like that do not happen through the usual mechanics and techniques. And doing the same from a filter... well... everything stated above is true here as well. The current situation is without a doubt a bug -- Emacs should detect that data was read and processed and not hang indefinitely. That we can agree on, I hope. :-) We could, by the way, avoid this whole problem and dilemma if we shift the processing of timers to _AFTER_ we are finished with everything. But this brings in new problems, like if we have to wait too long for the data to become available, timers would get delayed quite a bit. And they would only fire once, no matter how much time has passed. So this is not ideal as well. Again, I do not see the problem with my solution. We cannot and should not account for bugs in 3rd party package implementations like the one state earlier above. If I'm wrong here or missing something, please don't hesitate to correct me. Right now, at least, I am not seeing any problems. Have a nice weekend, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu