hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pty behaviour


From: Marcus Brinkmann
Subject: Re: pty behaviour
Date: Thu, 04 Mar 2004 05:47:48 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 03 Mar 2004 18:55:52 -0800,
Thomas Bushnell, BSG wrote:
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > The pty_io_write implementation drops (flushes) all input if the queue
> > is suspended (qavail returns 0).  This will be the case when the high
> > watermark is reached.  Thus, if screen uses a single write to its pty
> > end when the text is pasted, only up to the first 300 characters are
> > written.
> 
> This is (or used to be) normal Unix tty behavior.  If you were on a
> tty, and typed a bunch of characters which were not being read, then
> when the buffer gets full, the tty driver eventually stops reading
> input and beeps the bell.  So pty_io_write does just what all tty
> input does in this respect.

Maybe this is merely a matter of the right limit rather than the behaviour.

I just tried to paste a massive amount of data into screen under
GNU/Linux, and hey!  It gets stuck, flashes, and consumes 100% cpu
time for a long time (I interrupted it eventually).  So, this is
definitely worse behaviour than under the Hurd.

The test suite in the Perl IO::Tty module tested exactly for this
limit and complained about 300 being too small.  It wanted at least
512.  The limit in Linux for this perl test program was 8061 (odd
value, but what do I know).

So, if you say the behaviour is correct, and I am certainly following
your line of argumentation, then increasing the high watermark to
something like 4k or even 8k should be fine do avoid any problems
people wouldn't also have under GNU/Linux.

What do you think?

Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]