termios & non-blocking I/O

[Terry Lambert]

[ ... moved to -threads mailing list, instead of -arch ... ]

Alex Semenyaka wrote:
> On Tue, Apr 08, 2003 at 11:49:44PM +0400, Andrey A. Chernov wrote:
> > IEEE Std 1003.1-200x does not specify whether the setting of O_NONBLOCK
> > takes precedence over MIN or TIME settings. Therefore, if O_NONBLOCK is
> > set, read( ) may return immediately, regardless of the setting of MIN or
> > TIME. Also, if no data is available, read( ) may either return 0, or
> > return -1 with errno set to [EAGAIN].
> 
> Right you are, but the question is a little bit different, namely - what is
> _better_ to do: to return 0 or to return -1/EAGAIN.

-1/EAGAIN.

As was pointed out in Andrey Chernov's posting, the place to fix
this is libc_r, not the kernel, since the kernel is doing something
permissable, and the side effect you are seeing is a result of your
use of libc_r.


> Now the first choice
> is implemented. And the point IS that in multi-thread environment with
> utheads such implementation leads to BAD results.

Probably the correct thing to do is to use a blocking thread,
instead of one that uses VMIN/VTIME to poll the keyboard in the
first place.  In other words, an input processing thread.

Normally, this will only be a problem if someone tries to add a
thread to do some additional processing in some legacy code,
without properly maintaining the legacy code.


The main problem you will face, if you try to do this in the
kernel instead of libc_r, is that each time you call the read,
if it behaved the second way, you would stall all threads in
the process for VTIME, and you're going to have a hard time
getting people to sign off on blocking all threads because
one thread makes some call and the kernel captures it for a
long latency.

This is remarkably similar to the recent discussion about the
blocking of all threads in a libc_r program when taking a page
fault.

-- Terry