From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches) Date: Sat, 04 Nov 2017 14:11:55 +0200 Message-ID: <83r2tetf90.fsf@gnu.org> References: <83lgjz8eiy.fsf@gnu.org> <831slp98ut.fsf@gnu.org> <83tvyj62qg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1509797562 13167 195.159.176.226 (4 Nov 2017 12:12:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Nov 2017 12:12:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 04 13:12:02 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 1eAxIv-0001ed-RN for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2017 13:12:01 +0100 Original-Received: from localhost ([::1]:40826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAxJ1-0006v4-KH for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2017 08:12:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAxIu-0006uy-F6 for emacs-devel@gnu.org; Sat, 04 Nov 2017 08:12:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAxIp-0001AV-Mz for emacs-devel@gnu.org; Sat, 04 Nov 2017 08:12:00 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAxIp-0001AP-J0; Sat, 04 Nov 2017 08:11:55 -0400 Original-Received: from [176.228.60.248] (port=3676 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eAxIp-0006Tn-0f; Sat, 04 Nov 2017 08:11:55 -0400 In-reply-to: (message from Matthias Dahl on Mon, 30 Oct 2017 10:48:05 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:219917 Archived-At: > Cc: emacs-devel@gnu.org > From: Matthias Dahl > Date: Mon, 30 Oct 2017 10:48:05 +0100 > > > But if the wrong call to accept-process-output have read the process > > output, it could have also processed it and delivered the results to > > the wrong application, no? > > Given that fact that a filter is registered for a given process, and > thus it is this filter that gets called whenever process output is ready > and needs to be processed, a timer or filter would have to replace that > filter with its own through set-process-filter for this to happen. And > that is something I would clearly consider a bug, since no filter or > timer should do something like that. > > Naturally there is also the weird case when accept-process-output was > called from a hook by some package which expects that data and needs it > but doesn't consider that a timer could get called during that time and > the package itself has a timer setup that will also interact with that > very same process, trying to read data back from some interaction with > it. That will naturally fail as well... either way, with or without my > patch. And again, I would consider this a bug. OK. I think I'm okay with your patches, but IMO they need a minor improvement: instead of setting got_some_output to an arbitrary value of 1, the code should set it to the increment of the bytes read from the sub-process. This is what we do when we actually read from the process, and I think this scenario should behave the same. WDYT? With that change, it's okay to commit this to the master branch. Thanks.