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: Emacs deadlocks on sub-process reads and writes Date: Sat, 18 Oct 2014 18:48:43 -0700 (PDT) Message-ID: <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 1413683425 4698 80.91.229.3 (19 Oct 2014 01:50:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2014 01:50: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 03:50: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 1XffdT-0006HK-7K for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Oct 2014 03:50:19 +0200 Original-Received: from localhost ([::1]:38248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XffdS-0000uP-Sc for geh-help-gnu-emacs@m.gmane.org; Sat, 18 Oct 2014 21:50:18 -0400 X-Received: by 10.182.181.9 with SMTP id ds9mr12897107obc.16.1413683324197; Sat, 18 Oct 2014 18:48:44 -0700 (PDT) X-Received: by 10.50.73.4 with SMTP id h4mr87422igv.0.1413683324094; Sat, 18 Oct 2014 18:48:44 -0700 (PDT) Original-Path: usenet.stanford.edu!uq10no13391044igb.0!news-out.google.com!rp1ni32382igb.0!nntp.google.com!uq10no13391035igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help 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 01:48:44 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:208220 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:100496 Archived-At: I am debugging a Clang based code completer (irony-mode). Unfortunately the= transfer between Emacs and the Clang sub-process is slow on Windows. We ar= e experiencing frequent freeze-ups due to what looks like a deadlock. The d= eadlock happens under the following conditions: 1. Emacs reading a large transfer from the sub-process (2+MB, around 2 seco= nds to finish on Windows after setting w32-pipe-read-delay to 0); 2. While 1. is ongoing Emacs side send a new request to the sub-process. Th= e request is regular source file sized -- it includes the buffer content be= ing edited -- sufficient to cause a block on the write but nothing too big. When these two conditions are met, Emacs UI reliably locks up until the sub= -process is killed. The error message complaining about writing to a dead p= rocess after killing the sub-process shows that the Emacs was deadlocked wa= iting for the write to finish. The process buffer is half filled showing th= at the process filter function was no longer called. The write to the sub-p= rocess, which blocks the UI, can't proceed as it exceeds the size of the sm= all write buffer. The sub-process will not read on its side until it finish= es the transfer to Emacs. But for some reason Emacs also stopped reading fr= om the pipe. After poking around the Emacs code base a little bit it looks to me that wh= en you call process-send-* in lisp Emacs eventually calls send_process in p= rocess.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 text = received, calls the lisp process-filter. The logic in wait_reading_process_= output is too complicated for me to understand if somehow it may decide not= to call read_process_output, causing a deadlock. So I am asking for advice= here. A previous related question asked about transfer speed on Windows https://g= roups.google.com/forum/#!topic/gnu.emacs.help/Y0MYAz8WZUU I believe the slo= wness is the reason why this manifests itself on Windows but it may also ap= pear on Linux under the right conditions. For a very long thread of discuss= ion on this issue see https://github.com/Sarcasm/irony-mode/issues/131 Please feel free to forward to any Emacs list that may be relevant to solvi= ng this issue.