Messages in this thread | | | Date | Mon, 11 Aug 2008 11:41:32 -0600 | From | Joe Peterson <> | Subject | Re: tty: ctrl-c not always echoed, especially under load |
| |
Alan Cox wrote: > First thought would be to simply fire all output through your buffer in > n_tty. It's not a performance critical bit of code and it would still be > fast as the usual case would be > > if (queue->length == 0) > try_write_directly(...)
Only problem with that is that with a steady stream of output, you would likely end up quickly filling the new buffer and be right back to the same issue of losing echos and other ldisc chars off the start of the buf. Also, the regular output channel has the mechanism to throttle itself already and try again later (causing the upstream process to wait as expected - example: ping foo.com; hit ^S; it stops pinging until ^Q...).
What I may try is moving the code that manipulates the column marker (mostly "eraser") to happen at real output (i.e. when we know space is available), and have all ldisc echos/chars go into the buffer initially. That way, the regular output stream and ldisc stream (out of the buffer) will be able to control the column stuff properly and in sync. By knowing how many chars need to go out (eraser is the only non-trivial case, and we can have it tell us the char string before sending it), we can be sure there is space before trying and subsequently changing the column.
BTW, I'll also need to call the new buffer push function periodically after the output happens in case there are characters left to process. I suspect the right place is in the write wakeup func or the poll func. If you know off hand, let me know.
Thanks, Joe
| |