bug#6771: 24.0.50; Child process input isn't closed by process-send-eof; hangs indefinitely

["Štěpán Němec" <stepnem@gmail.com>]

Wolfgang Jenkner <wjenkner@inode.at> writes:

> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> I enabled ICANON.  If there is a long line problem (i.e. a too long
>> line to send_process may only send a partial line), please write a bug
>> report for it with a way to reproduce it.  That way we can fix it.  I
>> have not seen any problem or been able to reproduce the long line
>> problem.
>
> FWIW, such a problem does exist in the wild.
>
> The UIM emacs bridge (see [1]) sometimes sends long lines of about 20k
> of ASCII characters to the uim-el-helper-agent subprocess.
>
> Now, on FreeBSD 8-STABLE the maximum total size of a tty (or pty) input
> queue is 1920 bytes, cf. tty_watermarks() in [2] and the discussion in
> [3].  For Linux, judging from a superficial glance at tty_buffer_alloc()
> in [4], the bound seems to be a more comfortable 65536 bytes.
>
> For a self-contained example of what happens on breaking this bound,
> evaluate the following form (adjust 1923 to taste) and observe that the
> process output buffer contains only ASCII BEL (\C-g) characters, which
> is (modulo bogus references to MAX_INPUT and MAX_CANON) what termios(4)
> documents (search for IMAXBEL), i.e., the pseudo-terminal rings :-)
>
> (let* ((buf (generate-new-buffer "cat-out"))
>        (proc (start-process "cat" buf "cat")))
>   (process-send-string proc (make-string 1923 ?x))
>   (process-send-string proc "\n")
>   (pop-to-buffer buf))
>
> Of course, if line discipline features are not needed, a pipe can be
> used as a work-around (and I intend to submit a patch in this sense to
> the UIM developers or else to the FreeBSD port maintainer, which is one
> reason why I wanted to have this issue documented here).

Although it would certainly be nice if this limitation disappeared,
using pipes instead is not necessarily a work-around -- it might simply
be the better solution for what you are doing, for other reasons as
well. As the Elisp manual puts it (info "(elisp)Asynchronous Processes"):

 -- Variable: process-connection-type
     This variable controls the type of device used to communicate with
     asynchronous subprocesses.  If it is non-`nil', then PTYs are
     used, when available.  Otherwise, pipes are used.

     PTYs are usually preferable for processes visible to the user, as
     in Shell mode, because they allow job control (`C-c', `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 PTYs is limited on many systems and
     it is good not to waste them.


  Štěpán