Date: Wed, 09 Apr 2003 04:52:51 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Alex Semenyaka <alexs@ratmir.ru> Cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O Message-ID: <3E940993.FBAFFD70@mindspring.com> References: <20030408164614.GA7236@comp.chem.msu.su> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E940993.FBAFFD70>