From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: speech.free@gmail.com Newsgroups: gmane.emacs.help Subject: Re: Emacs deadlocks on sub-process reads and writes Date: Sat, 18 Oct 2014 23:38:15 -0700 (PDT) Message-ID: References: <2f4e5527-d9f0-4cfb-b20c-1b9dd110b7db@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1413700825 29491 80.91.229.3 (19 Oct 2014 06:40:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 06:40:25 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Oct 19 08:40:20 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XfkA7-0001Tj-W9 for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Oct 2014 08:40:20 +0200 Original-Received: from localhost ([::1]:38946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XfkA7-0006CH-GL for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Oct 2014 02:40:19 -0400 X-Received: by 10.236.222.166 with SMTP id t36mr13292693yhp.24.1413700695933; Sat, 18 Oct 2014 23:38:15 -0700 (PDT) X-Received: by 10.50.111.166 with SMTP id ij6mr98843igb.4.1413700695785; Sat, 18 Oct 2014 23:38:15 -0700 (PDT) Original-Path: usenet.stanford.edu!s7no3738844qap.0!news-out.google.com!rp1ni32382igb.0!nntp.google.com!uq10no13462469igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: <2f4e5527-d9f0-4cfb-b20c-1b9dd110b7db@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=108.202.5.152; posting-account=DWjLEQkAAADLnHA2oKd7rzKdWrb8mrBs Original-NNTP-Posting-Host: 108.202.5.152 User-Agent: G2/1.0 Injection-Date: Sun, 19 Oct 2014 06:38:15 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:208221 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100497 Archived-At: I can now verify that by locking out the blocking write we no longer have t= he deadlock. So this would appear to be an Emacs bug or feature. I am using= the Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN binary do= wnloaded from Gnu site. On Saturday, October 18, 2014 6:48:43 PM UTC-7, speec...@gmail.com wrote: > I am debugging a Clang based code completer (irony-mode). Unfortunately t= he transfer between Emacs and the Clang sub-process is slow on Windows. We = are experiencing frequent freeze-ups due to what looks like a deadlock. The= deadlock happens under the following conditions: >=20 >=20 >=20 > 1. Emacs reading a large transfer from the sub-process (2+MB, around 2 se= conds to finish on Windows after setting w32-pipe-read-delay to 0); >=20 >=20 >=20 > 2. While 1. is ongoing Emacs side send a new request to the sub-process. = The request is regular source file sized -- it includes the buffer content = being edited -- sufficient to cause a block on the write but nothing too bi= g. >=20 >=20 >=20 > When these two conditions are met, Emacs UI reliably locks up until the s= ub-process is killed. The error message complaining about writing to a dead= process after killing the sub-process shows that the Emacs was deadlocked = waiting for the write to finish. The process buffer is half filled showing = that the process filter function was no longer called. The write to the sub= -process, which blocks the UI, can't proceed as it exceeds the size of the = small write buffer. The sub-process will not read on its side until it fini= shes the transfer to Emacs. But for some reason Emacs also stopped reading = from the pipe. >=20 >=20 >=20 > After poking around the Emacs code base a little bit it looks to me that = when you call process-send-* in lisp Emacs eventually calls send_process in= process.c. If the send can't complete it calls wait_reading_process_output= , which calls read_and_dispose_of_process_output, which if there is new tex= t received, calls the lisp process-filter. The logic in wait_reading_proces= s_output is too complicated for me to understand if somehow it may decide n= ot to call read_process_output, causing a deadlock. So I am asking for advi= ce here. >=20 >=20 >=20 > A previous related question asked about transfer speed on Windows https:/= /groups.google.com/forum/#!topic/gnu.emacs.help/Y0MYAz8WZUU I believe the s= lowness is the reason why this manifests itself on Windows but it may also = appear on Linux under the right conditions. For a very long thread of discu= ssion on this issue see https://github.com/Sarcasm/irony-mode/issues/131 >=20 >=20 >=20 > Please feel free to forward to any Emacs list that may be relevant to sol= ving this issue.