* bug#33191: 26.1.50; remove remaining process input batching doc @ 2018-10-28 19:52 Charles A. Roelli 2018-12-09 10:45 ` Charles A. Roelli 0 siblings, 1 reply; 8+ messages in thread From: Charles A. Roelli @ 2018-10-28 19:52 UTC (permalink / raw) To: 33191 (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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-10-28 19:52 bug#33191: 26.1.50; remove remaining process input batching doc Charles A. Roelli @ 2018-12-09 10:45 ` Charles A. Roelli 2018-12-09 12:47 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Charles A. Roelli @ 2018-12-09 10:45 UTC (permalink / raw) To: charles; +Cc: 33191 > Date: Sun, 28 Oct 2018 20:52:34 +0100 > From: charles@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. */) ^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-09 10:45 ` Charles A. Roelli @ 2018-12-09 12:47 ` Eli Zaretskii 2018-12-09 16:15 ` Charles A. Roelli 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2018-12-09 12:47 UTC (permalink / raw) To: charles; +Cc: 33191 > Date: Sun, 09 Dec 2018 11:45:26 +0100 > From: charles@aurox.ch (Charles A. Roelli) > Cc: 33191@debbugs.gnu.org > > > Date: Sun, 28 Oct 2018 20:52:34 +0100 > > From: charles@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-09 12:47 ` Eli Zaretskii @ 2018-12-09 16:15 ` Charles A. Roelli 2018-12-09 16:32 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Charles A. Roelli @ 2018-12-09 16:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33191 > Date: Sun, 09 Dec 2018 14:47:54 +0200 > From: Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-09 16:15 ` Charles A. Roelli @ 2018-12-09 16:32 ` Eli Zaretskii 2018-12-09 19:24 ` Charles A. Roelli 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2018-12-09 16:32 UTC (permalink / raw) To: charles; +Cc: 33191 > Date: Sun, 09 Dec 2018 17:15:49 +0100 > From: charles@aurox.ch (Charles A. Roelli) > CC: 33191@debbugs.gnu.org > > > Date: Sun, 09 Dec 2018 14:47:54 +0200 > > From: Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-09 16:32 ` Eli Zaretskii @ 2018-12-09 19:24 ` Charles A. Roelli 2018-12-22 10:53 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Charles A. Roelli @ 2018-12-09 19:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33191 > Date: Sun, 09 Dec 2018 18:32:44 +0200 > From: Eli Zaretskii <eliz@gnu.org> > CC: 33191@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. */) ^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-09 19:24 ` Charles A. Roelli @ 2018-12-22 10:53 ` Eli Zaretskii 2018-12-22 16:17 ` Charles A. Roelli 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2018-12-22 10:53 UTC (permalink / raw) To: charles; +Cc: 33191 > Date: Sun, 09 Dec 2018 20:24:35 +0100 > From: charles@aurox.ch (Charles A. Roelli) > CC: 33191@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#33191: 26.1.50; remove remaining process input batching doc 2018-12-22 10:53 ` Eli Zaretskii @ 2018-12-22 16:17 ` Charles A. Roelli 0 siblings, 0 replies; 8+ messages in thread From: Charles A. Roelli @ 2018-12-22 16:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33191 tags 33191 fixed close 33191 26.2 quit > Date: Sat, 22 Dec 2018 12:53:29 +0200 > From: Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-12-22 16:17 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-28 19:52 bug#33191: 26.1.50; remove remaining process input batching doc Charles A. Roelli 2018-12-09 10:45 ` Charles A. Roelli 2018-12-09 12:47 ` Eli Zaretskii 2018-12-09 16:15 ` Charles A. Roelli 2018-12-09 16:32 ` Eli Zaretskii 2018-12-09 19:24 ` Charles A. Roelli 2018-12-22 10:53 ` Eli Zaretskii 2018-12-22 16:17 ` Charles A. Roelli
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).