all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
@ 2012-12-27 21:49 Vitalie Spinu
  2013-01-03  6:49 ` Glenn Morris
  0 siblings, 1 reply; 5+ messages in thread
From: Vitalie Spinu @ 2012-12-27 21:49 UTC (permalink / raw)
  To: 13290

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]


Hi, 

Comint can stall emacs while waiting for subproces output. I attach a
trivial patch.

Here is a short explanation. First comint calls comint-input-sender 

╭──────── #1842 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│         (let ((comint-input-sender-no-newline no-newline))
│           (funcall comint-input-sender proc input))
╰──────── #1843 ─

Then, if process echoes, comint first waits for process output:

╭──────── #1850 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│             (while (and (accept-process-output proc)
│                         (> (+ comint-last-input-end echo-len)
│                            (point-max))
╰──────── #1852 ─

The problem is that, occasionally, comint-input-sender might be a
non-trivial function and could take care of process output itself. Thus,
accept-process-output will wait for nonexistent output, and stall
emacs. The patch just reverts the order in the (and ...) above.

    Thanks, 
    Vitalie


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Avoid-hanging-emacs-by-complex-comint-input-senders.patch --]
[-- Type: text/x-diff, Size: 1693 bytes --]

From d3c2753a571688370a4bc8fa2254679d9c23b74a Mon Sep 17 00:00:00 2001
From: Vitalie Spinu <spinuvit@gmail.com>
Date: Thu, 27 Dec 2012 21:46:38 +0100
Subject: [PATCH] Avoid hanging emacs by complex comint input senders.

Revert the order of echo-len check and accept-process-output to avoid stalling
Emacs when there is no process output left.
---
 lisp/ChangeLog |    6 ++++++
 lisp/comint.el |    4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 5f4853d..cc94b0d 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,9 @@
+2012-12-27  Vitalie Spinu  <spinuvit@gmail.com>
+
+	* comint.el (comint-send-input): revert the order of echo-len
+	check and accept-process-output to avoid hanging Emacs when there
+	is no process output left.
+
 2012-12-27  Michael Albinus  <michael.albinus@gmx.de>
 
 	* net/tramp.el (tramp-handle-file-accessible-directory-p): New defun.
diff --git a/lisp/comint.el b/lisp/comint.el
index f3450e3..6477f00 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -1847,9 +1847,9 @@ Similarly for Soar, Scheme, etc."
           (let ((echo-len (- comint-last-input-end
                              comint-last-input-start)))
             ;; Wait for all input to be echoed:
-            (while (and (accept-process-output proc)
-                        (> (+ comint-last-input-end echo-len)
+            (while (and (> (+ comint-last-input-end echo-len)
                            (point-max))
+                        (accept-process-output proc)
                         (zerop
                          (compare-buffer-substrings
                           nil comint-last-input-start
-- 
1.7.10.4


[-- Attachment #3: Type: text/plain, Size: 335 bytes --]




In GNU Emacs 24.2.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.13)
 of 2012-12-25 on vitoshka-home
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.10

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
  2012-12-27 21:49 bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders Vitalie Spinu
@ 2013-01-03  6:49 ` Glenn Morris
  2013-01-03 10:47   ` Vitalie Spinu
  0 siblings, 1 reply; 5+ messages in thread
From: Glenn Morris @ 2013-01-03  6:49 UTC (permalink / raw)
  To: Vitalie Spinu; +Cc: 13290

Vitalie Spinu wrote:

> The problem is that, occasionally, comint-input-sender might be a
> non-trivial function and could take care of process output itself.

Thanks for the report. Could you give an example of this happening in
practice?





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
  2013-01-03  6:49 ` Glenn Morris
@ 2013-01-03 10:47   ` Vitalie Spinu
  2013-01-06 14:55     ` Vitalie Spinu
  0 siblings, 1 reply; 5+ messages in thread
From: Vitalie Spinu @ 2013-01-03 10:47 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 13290

  >> Glenn Morris <rgm@gnu.org>
  >> on Thu, 03 Jan 2013 01:49:03 -0500 wrote:

  > Vitalie Spinu wrote:
  >> The problem is that, occasionally, comint-input-sender might be a
  >> non-trivial function and could take care of process output itself.

  > Thanks for the report. Could you give an example of this happening in
  > practice?

Yes,  this was happening in ESS under some specific
conditions. Particularly when the user wants to evaluate the code
linewise, i.e. each line of code is echoed in the comint buffer, and
then the output is immediately inserted after that line.

This is implemented in comint-input-sender function, and it does nothing
else than just send input line by line and wait after each line for the
process output. Thus, after the execution of comint-input-sender there
was no process output left, and comint was waiting for nothing.

Cases like above, when both input and output should be manipulated, are
not easily implemented in comint-preoutput-filter-functions.

    Vitalie





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
  2013-01-03 10:47   ` Vitalie Spinu
@ 2013-01-06 14:55     ` Vitalie Spinu
  2013-01-07  1:07       ` Glenn Morris
  0 siblings, 1 reply; 5+ messages in thread
From: Vitalie Spinu @ 2013-01-06 14:55 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 13290


Would you mind adding this to emacs-24? This one really makes our life
at ESS difficult, and I cannot see a reliable workaround on our side.

Comint tweak, on the other side, is harmless and will preclude similar
problems in the future.  

    Thanks, 
    Vitalie

  >> Vitalie Spinu <spinuvit@gmail.com>
  >> on Thu, 03 Jan 2013 11:47:44 +0100 wrote:

  >> Glenn Morris <rgm@gnu.org>
  >> on Thu, 03 Jan 2013 01:49:03 -0500 wrote:

  >> Vitalie Spinu wrote:
  >> The problem is that, occasionally, comint-input-sender might be a
  >> non-trivial function and could take care of process output itself.

  >> Thanks for the report. Could you give an example of this happening in
  >> practice?

  VS> Yes,  this was happening in ESS under some specific
  VS> conditions. Particularly when the user wants to evaluate the code
  VS> linewise, i.e. each line of code is echoed in the comint buffer, and
  VS> then the output is immediately inserted after that line.

  VS> This is implemented in comint-input-sender function, and it does nothing
  VS> else than just send input line by line and wait after each line for the
  VS> process output. Thus, after the execution of comint-input-sender there
  VS> was no process output left, and comint was waiting for nothing.


  VS> Cases like above, when both input and output should be manipulated, are
  VS> not easily implemented in comint-preoutput-filter-functions.

  VS>     Vitalie





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders
  2013-01-06 14:55     ` Vitalie Spinu
@ 2013-01-07  1:07       ` Glenn Morris
  0 siblings, 0 replies; 5+ messages in thread
From: Glenn Morris @ 2013-01-07  1:07 UTC (permalink / raw)
  To: 13290-done

Version: 24.2.92

OK; applied.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-01-07  1:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-27 21:49 bug#13290: 24.2.91; [PATCH] Comint can stall emacs with non-trivial input senders Vitalie Spinu
2013-01-03  6:49 ` Glenn Morris
2013-01-03 10:47   ` Vitalie Spinu
2013-01-06 14:55     ` Vitalie Spinu
2013-01-07  1:07       ` Glenn Morris

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.