/hurd/term and input queue size

[Michael Teichgräber]

Hi,

I connected a Hurd box via the serial port to a small device.

(I have `/hurd/term /dev/com0 device com0' running on /dev/com0,
the Hurd system is from alpha.gnu.org..contrib/robertmh/gnu.tar.gz (09.07.2003))

It seems to me that some characters from the other box get lost:

If I send a certain char, the other box will answer with around 600
characters. But, my program only reads the first 256 characters
(wants: 4096), and--on another read call--the last 300 (or fewer,
depending on whether IMAXBEL is set). Characters in the middle get
lost. If IMAXBEL is set, /hurd/term will send some \a characters to
the other box. If it isn't, some more characters will get lost (this
seems to match the code starting at munge.c:566, CVS head).

In term/main.c an input queue of 256 characters gets created. And, in
munge.c, there is a realloc_queue function to double the size of the
input buffer. From the "last 300" one can see, that this function
actually got called, at least once. But even so the bell will ring or
characters will get lost -- why?

Shouldn't perhaps the high watermark get increased (doubled?) in
munge.c:760, when the queue size gets doubled? This would affect the
following condition in enqueue_internal, that will suspend the input
queue:

    if (!q->susp && (qsize (q) > q->hiwat))
      q->susp = 1;


BTW, I wonder why, if the input queue has been suspended and if
IMAXBEL is off, `everything' is dropped (munge.c:570). Couldn't `term'
wait until the queue size has been lowered below the low watermark,
and then clear the `susp' flag? Or just increase the queue?

-- 
Michael