From: Joe Peterson <joe@skyrush.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] fix n_tty/pty input/output buffer full and other misc char handling
Date: Wed, 22 Oct 2008 13:35:23 -0600 [thread overview]
Message-ID: <48FF807B.2020002@skyrush.com> (raw)
In-Reply-To: <20081022103259.2d04729a@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> that ^C, ^Q, etc. can have effect) in non-canonical mode? This would
>> allow prevention of the gridlocks that still can be invoked when using
>> stty -icanon in, say, an xterm. For now, I took the conservative route
>> in this patch, but let me know if a more permissive approach is better.
>
> I suspect having thought about this a bit more that the proper logic is
> in fact
>
> if (special case a)
> if (special case b)
> if (....)
>
> /* An ordinary character for the queue */
> if (queue_full) { ....}
>
> and we should process everything that may have a special effect (flow
> control, delete line, etc) before worrying about having room to store the
> character whatever the tty ldisc state
Yeah, I had thought about this a little before too. The tricky part is
knowing that such a character exists and is waiting when we have already
stopped accepting characters. In the current way things work, a ^C, for
example, will not make it into the line discipline until the stuff that
came before has been processed (which is now wedged waiting for space to
free up), so it's hard to check in the ldisc for it. I'm guessing that
is why the orignal logic in set_room was designed to lets stuff flow in
in that case when we're looking for an erase char...
Now, in the case of a ^C or ^Q (e.g.), if we knew one was back in the
queue waiting to get to the ldisc, we could put it through out of
sequence, but for an erase (e.g.), it needs to wait for what real chars
come before it (i.e. it cannot jump to the front)...
I'll think more on this, too - let me know if I am not hearing what you
are saying exactly.
-Joe
next prev parent reply other threads:[~2008-10-22 19:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 6:01 [PATCH] fix n_tty/pty input/output buffer full and other misc char handling Joe Peterson
2008-10-13 8:40 ` Alan Cox
2008-10-22 9:32 ` Alan Cox
2008-10-22 19:35 ` Joe Peterson [this message]
2008-10-23 1:33 ` Joe Peterson
2008-10-23 1:34 ` [PATCH] n-tty-fix-cont-and-ctrl-output Joe Peterson
2008-10-24 8:57 ` Alan Cox
2008-10-23 1:35 ` [PATCH] n-tty-fix-buffer-full-checks Joe Peterson
2008-10-23 1:35 ` [PATCH] n-tty-output-bells-immediately Joe Peterson
2008-10-24 9:10 ` Alan Cox
2008-10-25 15:41 ` Joe Peterson
2008-10-25 15:48 ` Alan Cox
2008-10-25 15:53 ` Joe Peterson
2008-10-25 21:13 ` Joe Peterson
2008-10-23 1:36 ` [PATCH] n-tty-fix-buffer-full-gridlock Joe Peterson
2008-10-23 1:56 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48FF807B.2020002@skyrush.com \
--to=joe@skyrush.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox