From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18396: 24.3.1; On windows, process-send-string can freeze Emacs Date: Thu, 04 Sep 2014 05:51:45 +0300 Message-ID: <83y4u0gkse.fsf@gnu.org> References: <87k35kod3w.fsf@loki.jorgenschaefer.de> <831trsinu3.fsf@gnu.org> <20140903204307.0bcf515c@forcix> <83zjegh6kh.fsf@gnu.org> <20140903212833.14562b90@forcix> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409799147 25409 80.91.229.3 (4 Sep 2014 02:52:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 02:52:27 +0000 (UTC) Cc: 18396@debbugs.gnu.org To: Jorgen Schaefer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 04 04:52:20 2014 Return-path: Envelope-to: geb-bug-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 1XPN9n-0005df-Nh for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Sep 2014 04:52:19 +0200 Original-Received: from localhost ([::1]:48534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPN9n-0007cB-By for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2014 22:52:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPN9c-0007Q1-SN for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 22:52:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPN9W-0006ZY-H1 for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 22:52:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPN9W-0006ZU-Eh for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 22:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XPN9V-0007Au-U0 for bug-gnu-emacs@gnu.org; Wed, 03 Sep 2014 22:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2014 02:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18396 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 18396-submit@debbugs.gnu.org id=B18396.140979910527552 (code B ref 18396); Thu, 04 Sep 2014 02:52:01 +0000 Original-Received: (at 18396) by debbugs.gnu.org; 4 Sep 2014 02:51:45 +0000 Original-Received: from localhost ([127.0.0.1]:58275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPN9E-0007AJ-Gg for submit@debbugs.gnu.org; Wed, 03 Sep 2014 22:51:44 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:54529) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XPN9A-00079z-Q9 for 18396@debbugs.gnu.org; Wed, 03 Sep 2014 22:51:42 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NBC00500UOB4P00@mtaout29.012.net.il> for 18396@debbugs.gnu.org; Thu, 04 Sep 2014 05:51:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBC003CVVXMVT40@mtaout29.012.net.il>; Thu, 04 Sep 2014 05:51:22 +0300 (IDT) In-reply-to: <20140903212833.14562b90@forcix> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:93013 Archived-At: > Date: Wed, 3 Sep 2014 21:28:33 +0200 > From: Jorgen Schaefer > Cc: 18396@debbugs.gnu.org > > On Wed, 03 Sep 2014 22:01:18 +0300 > Eli Zaretskii wrote: > > > > Date: Wed, 3 Sep 2014 20:43:07 +0200 > > > From: Jorgen Schaefer > > > Cc: 18396@debbugs.gnu.org > > > > > > > Using "/" as the default directory on Windows is a bad idea, as > > > > that is not a fully-qualified absolute file name. > > > > > > What would be the equivalent for "out of the way and not blocking > > > any mount point" (or equivalent) on Windows? > > > > I might have a suggestion, if you explain what "out of the way" and > > "not blocking any mount points" mean. > > The primary reason Elpy starts the process in "/" is to avoid > accidental imports of Python modules. As the process is started from a > Python buffer, there often are Python files in the current directory, > which can accidentally be imported. "/" is unlikely to have Python > modules. Why not use ~/, then? > Also, a current directory of "/" means the process won't > accidentally block a mount point, much like why daemons chdir to /. I'm > not sure if this concept makes sense in Windows. (expand-file-name "/") should do what you want, I think. > > > > Looks like the write to the pipe never returned. This could be > > > > because the pipe is full and is not being read from the other end > > > > (Windows pipes have 4K buffers, and you show above more than 6K of > > > > data). > > > > > > That is quite likely the explanation. The Python process does the > > > equivalent of a REPL, reading one RPC call, evaluating it, and > > > writing the response. If in the duration of that evaluation Emacs > > > sends more than 4k of data, it will hang. If the response is larger > > > than 4k, Python in turn will hang. Resulting in a deadlock. > > > > > > Am I missing something? > > > > I'd expect Python to continue reading from the pipe once it evaluated > > one call and sent back the response. It should see that more input is > > available and continue reading. > > But if the sending of the response runs into the same problem? Each direction of the pipe has its own separate buffering, so this is unlikely. > The response can contain docstrings and can easily be larger than > 4k, so it's conceivable that Python sends more than 4k of data as > well, which would block the Python process, too? And thus prevent it > from reading, which keeps Emacs blocked? Emacs reads in a separate thread, so again, unlikely. > > Could this be an end-of-line format issue? Are you sure the commands > > used from Emacs side produce Windows-style CRLF EOLs? Or maybe they > > do, but Python expects Unix-style newline-only EOLs (maybe it's a > > Cygwin or MSYS Python, for example)? A wrong EOL format might cause > > Python to fail to realize it was handed a full line of input. > > Unlikely. The RPC calls work perfectly fine most of the time Perhaps this user has a different kind of Python than others. > > > Does Emacs have a chance to check for a pipe to be writable before > > > doing so? The whole process blocking like this feels a bit weird. > > > > I don't know how to do such a check with pipes on Windows. More > > importantly, how would that help? The pipe will fill up anyway, and > > the communications with Python will stop. Being able to interrupt > > with C-g vs killing the subprocess is not such a big win, IMO. > > Well, if the deadlock hypothesis is correct, Emacs would check if the > pipe is writable, notice that it isn't and keep checking, to notice > that the pipe is readable, read data, and thus break the deadlock. See above: there's no interconnection between reading and writing, so that's not the problem.