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

[Wolfgang Jenkner]

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

[1] http://code.google.com/p/uim/wiki/UIM_EL

[2] http://svn.freebsd.org/viewvc/base/stable/8/sys/kern/tty.c?view=markup

[3] http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052318.html

[3] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/tty/tty_buffer.c;hb=HEAD