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: Wed, 25 Oct 2017 17:53:41 +0300 Message-ID: <83lgjz8eiy.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1508943313 14608 195.159.176.226 (25 Oct 2017 14:55:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2017 14:55:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 25 16:55:03 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 1e7N4z-0001B4-1F for ged-emacs-devel@m.gmane.org; Wed, 25 Oct 2017 16:54:49 +0200 Original-Received: from localhost ([::1]:48657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7N56-0008NG-5W for ged-emacs-devel@m.gmane.org; Wed, 25 Oct 2017 10:54:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7N49-0008MJ-R8 for emacs-devel@gnu.org; Wed, 25 Oct 2017 10:54:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7N46-0000dm-Kq for emacs-devel@gnu.org; Wed, 25 Oct 2017 10:53:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7N46-0000dc-HA; Wed, 25 Oct 2017 10:53:54 -0400 Original-Received: from [176.228.60.248] (port=4881 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e7N45-00007T-UK; Wed, 25 Oct 2017 10:53:54 -0400 In-reply-to: (message from Matthias Dahl on Tue, 24 Oct 2017 20:52:20 +0200) 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:219751 Archived-At: > From: Matthias Dahl > Date: Tue, 24 Oct 2017 20:52:20 +0200 > > recursively calling accept-process-output with the first call waiting > for the output of a specific process, can hang Emacs (as-in: it is > waiting forever but can be canceled of course) even though it should > not be the case since data was read. > > This is actually not all that uncommon. One example of this is a hang > seen with Magit opening its COMMIT_MSG buffer, reported here [1]. I've > myself run into this problem continuously which is why I started to > debug it in the first place. > > The hang with Magit happens in flyspell.el which waits for output from > its spellchecker process through accept-process-output and specifies > that specific process as wait_proc. Now depending on timing (race), > wait_reading_process_output can call the pending timers... which in > turn can call accept-process-output again. This almost always leads > to the spellchecker output being read back in full, so there is no > more data left to be read. Thus the original accept-process-output, > which called wait_reading_process_output, will wait for the data to > become available forever since it has no way to know that those have > already been read. I'm not sure I understand the situation where this happens; can you elaborate? Are you saying that a Lisp program calls accept-process-output and waits for a specific process to produce some output, and meanwhile some timer runs a function that calls accept-process-output with its 1st argument nil? What timers do that? I think this would be a bug in such timers. Or are you saying that a Lisp program calls accept-process-output with its 1st arg nil, and while it waits, a timer calls accept-process-output for a specific process? Or do you mean something else? Thanks.