procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Lisp manual -- improve discussion of ptys vs pipes.

Browse source 
* processes.texi (Asynchronous Processes): Make the pty vs pipe
discussion more prominent.
This commit is contained in:
Thien-Thi Nguyen 2012-06-24 17:30:35 +08:00 • committed by Chong Yidong
parent f1dd807386
commit 6d41a41d81
2 changed files with 25 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
doc/lispref/ChangeLog
View file

@ -1,3 +1,8 @@
2012-06-24 Thien-Thi Nguyen <ttn@gnuvola.org>
* processes.texi (Asynchronous Processes): Make the pty vs pipe
discussion more prominent.
2012-06-23 Eli Zaretskii <eliz@gnu.org>
* commands.texi (Misc Events): Document the language-change event.

37
doc/lispref/processes.texi
View file

@ -541,16 +541,29 @@ is decoded in the same way as for @code{call-process}.
@section Creating an Asynchronous Process
@cindex asynchronous subprocess
After an @dfn{asynchronous process} is created, Emacs and the subprocess
both continue running immediately. The process thereafter runs
in parallel with Emacs, and the two can communicate with each other
using the functions described in the following sections. However,
In this section, we describe how to create an @dfn{asynchronous
process}. After an asynchronous process is created, it runs in
parallel with Emacs, and Emacs can communicate with it using the
functions described in the following sections (@pxref{Input to
Processes}, and @pxref{Output from Processes}). Note that process
communication is only partially asynchronous: Emacs sends data to the
process only when certain functions are called, and Emacs accepts data
from the process only when Emacs is waiting for input or for a time
delay.
from the process only while waiting for input or for a time delay.
Here we describe how to create an asynchronous process.
@cindex pty
@cindex pipe
An asynchronous process is controlled either via a @dfn{pty}
(pseudo-terminal) or a @dfn{pipe}. The choice of pty or pipe is made
when creating the process, based on the value of the variable
@code{process-connection-type} (see below). Ptys are usually
preferable for processes visible to the user, as in Shell mode,
because they allow for job control (@kbd{C-c}, @kbd{C-z}, etc.)
between the process and its children, whereas pipes do not. For
subprocesses used for internal purposes by programs, it is often
better to use a pipe, because they 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.
@defun start-process name buffer-or-name program &rest args
This function creates a new asynchronous subprocess and starts the
@ -652,20 +665,10 @@ can also be executed on remote hosts, depending on @code{default-directory}.
@end defun
@defvar process-connection-type
@cindex pipes
@cindex @acronym{PTY}s
This variable controls the type of device used to communicate with
asynchronous subprocesses. If it is non-@code{nil}, then @acronym{PTY}s are
used, when available. Otherwise, pipes are used.
@acronym{PTY}s are usually preferable for processes visible to the user, as
in Shell mode, because they allow job control (@kbd{C-c}, @kbd{C-z},
etc.) to work between the process and its children, whereas pipes do
not. For subprocesses used for internal purposes by programs, it is
often better to use a pipe, because they are more efficient. In
addition, the total number of @acronym{PTY}s is limited on many systems and
it is good not to waste them.
The value of @code{process-connection-type} takes effect when
@code{start-process} is called. So you can specify how to communicate
with one subprocess by binding the variable around the call to