all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Philipp <p.stephani2@gmail.com>
Cc: 33839-done@debbugs.gnu.org
Subject: bug#33839: 26.1.90; Emacs occasionally fails to receive asynchronous subprocess output in batch mode
Date: Thu, 27 Dec 2018 13:06:54 -0800	[thread overview]
Message-ID: <d3b67d41-a076-1222-8fa4-40cff1569295@cs.ucla.edu> (raw)
In-Reply-To: <m21s699dsq.fsf@gmail.com>

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

[This is a corrected version of email I mistakenly sent elsewhere.]

 > I don't think the manual states that output can
 > arrive after the process has finished, but if that's the case, then it
 > should do so.

Good point, and I installed the attached patch into emacs-26 to try to do that.

As this bug report seems to stem from a misunderstanding of 
accept-process-output (quite understandable, as its functionality is obscure) 
I'm taking the liberty of closing the report. If I'm wrong please feel free to 
reopen it.

[-- Attachment #2: 0001-Improve-accept-process-process-doc.patch --]
[-- Type: text/x-patch, Size: 3028 bytes --]

From c9fdd1b4965ebd02aa408f878320c4955f5e2cc7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 27 Dec 2018 12:52:45 -0800
Subject: [PATCH] Improve accept-process-process doc

* doc/lispref/processes.texi (Accepting Output):
* src/process.c (Faccept_process_output):
Document that (accept-process-output P) can return non-nil
even after P has exited, and that it can return nil even if P
is still running (Bug#33839).
---
 doc/lispref/processes.texi | 7 +++++--
 src/process.c              | 7 ++++---
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index 623be09cc6..2aca7f82a1 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -1795,7 +1795,8 @@ Accepting Output
 This function allows Emacs to read pending output from processes.  The
 output is given to their filter functions.  If @var{process} is
 non-@code{nil} then this function does not return until some output
-has been received from @var{process}.
+has been received from @var{process} or @var{process} has closed the
+connection.
 
 The arguments @var{seconds} and @var{millisec} let you specify timeout
 periods.  The former specifies a period measured in seconds and the
@@ -1820,7 +1821,9 @@ Accepting Output
 
 The function @code{accept-process-output} returns non-@code{nil} if it
 got output from @var{process}, or from any process if @var{process} is
-@code{nil}.  It returns @code{nil} if the timeout expired before output
+@code{nil}; this can occur even after a process has exited if the
+corresponding connection contains buffered data.  The function returns
+@code{nil} if the timeout expired or the connection was closed before output
 arrived.
 @end defun
 
diff --git a/src/process.c b/src/process.c
index e306b2ae9e..4dafee8cbe 100644
--- a/src/process.c
+++ b/src/process.c
@@ -4581,8 +4581,8 @@ DEFUN ("accept-process-output", Faccept_process_output, Saccept_process_output,
        0, 4, 0,
        doc: /* Allow any pending output from subprocesses to be read by Emacs.
 It is given to their filter functions.
-Optional argument PROCESS means do not return until output has been
-received from PROCESS.
+Optional argument PROCESS means to return only after output is
+received from PROCESS or PROCESS closes the connection.
 
 Optional second argument SECONDS and third argument MILLISEC
 specify a timeout; return after that much time even if there is
@@ -4594,7 +4594,8 @@ If optional fourth argument JUST-THIS-ONE is non-nil, accept output
 from PROCESS only, suspending reading output from other processes.
 If JUST-THIS-ONE is an integer, don't run any timers either.
 Return non-nil if we received any output from PROCESS (or, if PROCESS
-is nil, from any process) before the timeout expired.  */)
+is nil, from any process) before the timeout expired or the
+corresponding connection was closed.  */)
   (Lisp_Object process, Lisp_Object seconds, Lisp_Object millisec,
    Lisp_Object just_this_one)
 {
-- 
2.17.1


      parent reply	other threads:[~2018-12-27 21:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-23  2:28 bug#33839: 26.1.90; Emacs occasionally fails to receive asynchronous subprocess output in batch mode Philipp
2018-12-23 15:21 ` Eli Zaretskii
2018-12-23 16:45   ` Philipp Stephani
2018-12-23 16:54     ` Eli Zaretskii
2018-12-25 16:41       ` Philipp Stephani
2018-12-25 17:28         ` Eli Zaretskii
2018-12-25 16:38     ` Philipp Stephani
2018-12-27 21:06 ` Paul Eggert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3b67d41-a076-1222-8fa4-40cff1569295@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=33839-done@debbugs.gnu.org \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.