GNU bug report logs - #33191
26.1.50; remove remaining process input batching doc

Previous Next

Package: emacs;

Reported by: charles <at> aurox.ch

Date: Sun, 28 Oct 2018 19:53:02 UTC

Severity: minor

Tags: fixed

Found in version 26.1.50

Fixed in version 26.2

Done: charles <at> aurox.ch

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33191 in the body.
You can then email your comments to 33191 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 28 Oct 2018 19:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to charles <at> aurox.ch:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 28 Oct 2018 19:53:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1.50; remove remaining process input batching doc
Date: Sun, 28 Oct 2018 20:52:34 +0100
(as discussed in Bug#33050#116)

- Remove mention of "stray character injections" in Elisp node
  "Asynchronous Processes".
- Remove doc of "process-send-string" and "process-send-region" 
  claiming to split process input every 500 characters.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 09 Dec 2018 10:42:01 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: charles <at> aurox.ch
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 26.1.50; remove remaining process input batching doc
Date: Sun, 09 Dec 2018 11:45:26 +0100
> Date: Sun, 28 Oct 2018 20:52:34 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> 
> (as discussed in Bug#33050#116)
> 
> - Remove mention of "stray character injections" in Elisp node
>   "Asynchronous Processes".
> - Remove doc of "process-send-string" and "process-send-region" 
>   claiming to split process input every 500 characters.

Here's a suggested change for emacs-26:

diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index e7d61bd..623be09 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -604,10 +604,9 @@ Asynchronous Processes
 internal purposes (i.e., no user interaction with the subprocess is
 required), where significant amounts of data need to be exchanged
 between the subprocess and the Lisp program, it is often better to use
-a pipe, because pipes are more efficient, and because they are immune
-to stray character injections that ptys introduce for large (around
-500 byte) messages.  Also, the total number of ptys is limited on many
-systems, and it is good not to waste them unnecessarily.
+a pipe, because pipes are more efficient.  Also, the total number of
+ptys is limited on many systems, and it is good not to waste them
+unnecessarily.
 
 @defun make-process &rest args
 This function is the basic low-level primitive for starting
diff --git a/src/process.c b/src/process.c
index b0a3272..90e0f64 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6456,9 +6456,6 @@ DEFUN ("process-send-region", Fprocess_send_region, Sprocess_send_region,
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
 Called from program, takes three arguments, PROCESS, START and END.
-If the region is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter regions.
-Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)
@@ -6489,9 +6486,6 @@ DEFUN ("process-send-string", Fprocess_send_string, Sprocess_send_string,
        doc: /* Send PROCESS the contents of STRING as input.
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
-If STRING is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter strings.
-Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 09 Dec 2018 12:49:01 GMT) Full text and rfc822 format available.

Message #11 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sun, 09 Dec 2018 14:47:54 +0200
> Date: Sun, 09 Dec 2018 11:45:26 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> Cc: 33191 <at> debbugs.gnu.org
> 
> > Date: Sun, 28 Oct 2018 20:52:34 +0100
> > From: charles <at> aurox.ch (Charles A. Roelli)
> > 
> > (as discussed in Bug#33050#116)
> > 
> > - Remove mention of "stray character injections" in Elisp node
> >   "Asynchronous Processes".
> > - Remove doc of "process-send-string" and "process-send-region" 
> >   claiming to split process input every 500 characters.
> 
> Here's a suggested change for emacs-26:

Thanks, but this removes too much, IMO.  The 500 bytes figure should
go away, but we still send the string in chunks, albeit
system-dependent ones, and we still allow output from processes to
arrive between chunks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 09 Dec 2018 16:12:01 GMT) Full text and rfc822 format available.

Message #14 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sun, 09 Dec 2018 17:15:49 +0100
> Date: Sun, 09 Dec 2018 14:47:54 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Thanks, but this removes too much, IMO.  The 500 bytes figure should
> go away, but we still send the string in chunks, albeit
> system-dependent ones, and we still allow output from processes to
> arrive between chunks.

True, but it seems like chunked sending is broken somehow: Bug#6149
(GNU/Linux) and Bug#32438 (macOS) both show this.  (There may be
similar problems on MS Windows; I have not tested.)  If we say that
sending is done in chunks, users might infer that there are no such
problems.  Maybe we can add that system-dependent problems may occur
for input longer than 1 kB.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 09 Dec 2018 16:34:01 GMT) Full text and rfc822 format available.

Message #17 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sun, 09 Dec 2018 18:32:44 +0200
> Date: Sun, 09 Dec 2018 17:15:49 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 33191 <at> debbugs.gnu.org
> 
> > Date: Sun, 09 Dec 2018 14:47:54 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > Thanks, but this removes too much, IMO.  The 500 bytes figure should
> > go away, but we still send the string in chunks, albeit
> > system-dependent ones, and we still allow output from processes to
> > arrive between chunks.
> 
> True, but it seems like chunked sending is broken somehow: Bug#6149
> (GNU/Linux) and Bug#32438 (macOS) both show this.

The former is supposed to be solved.

> (There may be similar problems on MS Windows; I have not tested.)
> If we say that sending is done in chunks, users might infer that
> there are no such problems.

I don't see how such a conclusion could follow.  IMO, it's important
to tell that we send large strings in smaller chunks, because
otherwise some phenomena might come as a surprise.

> Maybe we can add that system-dependent problems may occur for input
> longer than 1 kB.

I don't think we should document bugs.  We should solve them instead.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sun, 09 Dec 2018 19:21:02 GMT) Full text and rfc822 format available.

Message #20 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sun, 09 Dec 2018 20:24:35 +0100
> Date: Sun, 09 Dec 2018 18:32:44 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> CC: 33191 <at> debbugs.gnu.org
>
> > True, but it seems like chunked sending is broken somehow: Bug#6149
> > (GNU/Linux) and Bug#32438 (macOS) both show this.
> 
> The former is supposed to be solved.

I re-opened it at the end of September, I think.

> > (There may be similar problems on MS Windows; I have not tested.)
> > If we say that sending is done in chunks, users might infer that
> > there are no such problems.
> 
> I don't see how such a conclusion could follow.  IMO, it's important
> to tell that we send large strings in smaller chunks, because
> otherwise some phenomena might come as a surprise.

Fair enough.  Maybe I've confused the "chunk" issue with the issue of
sending large strings, which might not always be related.

> > Maybe we can add that system-dependent problems may occur for input
> > longer than 1 kB.
> 
> I don't think we should document bugs.  We should solve them instead.

Okay.  In the meantime, how about the following amended change?  It
replaces the "500 character" limit with the idea of the "input buffer"
limit (which is itself dependent on the process connection type and
the OS).


diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index e7d61bd..623be09 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -604,10 +604,9 @@ Asynchronous Processes
 internal purposes (i.e., no user interaction with the subprocess is
 required), where significant amounts of data need to be exchanged
 between the subprocess and the Lisp program, it is often better to use
-a pipe, because pipes are more efficient, and because they are immune
-to stray character injections that ptys introduce for large (around
-500 byte) messages.  Also, the total number of ptys is limited on many
-systems, and it is good not to waste them unnecessarily.
+a pipe, because pipes are more efficient.  Also, the total number of
+ptys is limited on many systems, and it is good not to waste them
+unnecessarily.
 
 @defun make-process &rest args
 This function is the basic low-level primitive for starting
diff --git a/src/process.c b/src/process.c
index b0a3272..e306b2a 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6456,9 +6456,11 @@ DEFUN ("process-send-region", Fprocess_send_region, Sprocess_send_region,
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
 Called from program, takes three arguments, PROCESS, START and END.
-If the region is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter regions.
-Output from processes can arrive in between bunches.
+If the region is larger than the input buffer of the process (the
+length of which depends on the process connection type and the
+operating system), it is sent in several bunches.  This may happen
+even for shorter regions.  Output from processes can arrive in between
+bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)
@@ -6489,9 +6491,10 @@ DEFUN ("process-send-string", Fprocess_send_string, Sprocess_send_string,
        doc: /* Send PROCESS the contents of STRING as input.
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
-If STRING is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter strings.
-Output from processes can arrive in between bunches.
+If STRING is larger than the input buffer of the process (the length
+of which depends on the process connection type and the operating
+system), it is sent in several bunches.  This may happen even for
+shorter strings.  Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sat, 22 Dec 2018 10:54:01 GMT) Full text and rfc822 format available.

Message #23 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sat, 22 Dec 2018 12:53:29 +0200
> Date: Sun, 09 Dec 2018 20:24:35 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 33191 <at> debbugs.gnu.org
> 
> Okay.  In the meantime, how about the following amended change?  It
> replaces the "500 character" limit with the idea of the "input buffer"
> limit (which is itself dependent on the process connection type and
> the OS).

LGTM, thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33191; Package emacs. (Sat, 22 Dec 2018 16:13:02 GMT) Full text and rfc822 format available.

Message #26 received at 33191 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33191 <at> debbugs.gnu.org
Subject: Re: bug#33191: 26.1.50; remove remaining process input batching doc
Date: Sat, 22 Dec 2018 17:17:28 +0100
tags 33191 fixed
close 33191 26.2
quit

> Date: Sat, 22 Dec 2018 12:53:29 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Okay.  In the meantime, how about the following amended change?  It
> > replaces the "500 character" limit with the idea of the "input buffer"
> > limit (which is itself dependent on the process connection type and
> > the OS).
> 
> LGTM, thanks.

Thanks, it's pushed to emacs-26.




Added tag(s) fixed. Request was from charles <at> aurox.ch (Charles A. Roelli) to control <at> debbugs.gnu.org. (Sat, 22 Dec 2018 16:13:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 26.2, send any further explanations to 33191 <at> debbugs.gnu.org and charles <at> aurox.ch Request was from charles <at> aurox.ch (Charles A. Roelli) to control <at> debbugs.gnu.org. (Sat, 22 Dec 2018 16:13:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 20 Jan 2019 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 90 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.