[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pty behaviour
From: |
Marcus Brinkmann |
Subject: |
pty behaviour |
Date: |
Wed, 03 Mar 2004 01:53:46 +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) |
Hi,
I figured out why screen doesn't support cut&paste of more than 300
characters. This is the high watermark in term.
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.
pty_io_write does in particular not suspend the write, wait on the
queue condition and continue after the queue is drained below the low
watermark and unsuspended.
I couldn't find a description of what pty's are supposed to do on
read/write. However, screen seems to expect to be able to do it, and
screen is widely ported. Actually, I tried to find out what screen is
trying to do (ie if it splits up the input in chunks etc), but the
code is a horrid mess (it's slowpaste option worked, though, IIRC, as
it sends input char by char). Likewise I saw a perl pty test fail due
to this.
So, is there anything I am missing? Shouldn't we implement
pty_io_write as any other writer, with suspending behaviour unless
O_NONBLOCK is set (if that is even possible for a pty)?
Thanks,
Marcus
- pty behaviour,
Marcus Brinkmann <=
- Re: pty behaviour, Thomas Bushnell, BSG, 2004/03/06
- Re: pty behaviour, Roland McGrath, 2004/03/10
- Re: pty behaviour, Thomas Bushnell, BSG, 2004/03/10
- Re: pty behaviour, Marcus Brinkmann, 2004/03/10