lkml.org 
[lkml]   [2007]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tcsetattr(fd, TCSAFLUSH) on an O_ASYNC pts device always fails
On Tue, 27 Nov 2007 13:53:21 -0500
Jeff Dike <jdike@addtoit.com> wrote:

> tcsetattr(fd, TCSAFLUSH) will always return -EINTR on a pts device
> when O_ASYNC has been set. This is demonstrated by the test program
> below - just compile and follow the instructions. You'll get an
> infinite stream of SIGIOs and -EINTRs.

Cute. This appears to be entirely standards compliant but I agree its not
sane or expected behaviour.

> static void pty_unthrottle(struct tty_struct * tty)
> {
> ...
> tty_wakeup(o_tty);
> set_bit(TTY_THROTTLED, &tty->flags);
> }

My first thought would be to only do the tty_wakeup if there is data
pending.

> I'd love to get rid of the set_bit(TTY_THROTTLED, &tty->flags) in
> pty_unthrottle, but it's protected by this comment:
>
> /* For PTY's, the TTY_THROTTLED
> * flag is always set, to force the line discipline to always call the
> * unthrottle routine when there are fewer than TTY_THRESHOLD_UNTHROTTLE
> * characters in the queue. This is necessary since each time this
> * happens, we need to wake up any sleeping processes that could be
> * (1) trying to send data to the pty, or (2) waiting in wait_until_sent()
> * for the pty buffer to be drained.
> */
>
> Failing that, there should be a relevant state change in the device
> before it will deliver a SIGIO. I just have no idea where to put it.

Unfortunately neither am I. If the wakeup can be deferred if there is no
data pending then I think that will do the trick ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-29 01:19    [W:0.047 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site