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
prev 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.