Date: Wed, 9 Apr 2003 16:34:31 +0400 From: Alex Semenyaka <alexs@ratmir.ru> To: Terry Lambert <tlambert2@mindspring.com> Cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O Message-ID: <20030409123431.GD33144@snark.ratmir.ru> In-Reply-To: <3E940993.FBAFFD70@mindspring.com> References: <20030408164614.GA7236@comp.chem.msu.su> <20030409044301.J628@gamplex.bde.org> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> <3E940993.FBAFFD70@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 09, 2003 at 04:52:51AM -0700, Terry Lambert 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. > 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. Yes it is permissable, it is just in the disagreement with the behaviour when MIN>0 and TIME=0. Don't you think the behaviour in the (TIME=0, MIN>0) and (TIME>0, MIN=0) should be consistent somehow? Then, changing the kernel behavour is simple, straightforward and also PERFECTLY permissable while tracing the situation with the descriptor mode in libc_r is not so simple. To be fair such tracing might be a difficult task. >> Now the first choice >> is implemented. And the point IS that in multi-thread environment with >> utheads such implementation leads to BAD results. > 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 No, sorry, you have missed my point. Sure I do NOT propose to block the input when TIME>0. I propose to return -1/EAGAIN (as in the MIN>0 case) instead of 0 (as it is done now). That is what I called "the second way". And in this case both libc_r and program can easely distinct between EOF and nothing-to-read situation and handle them properly. Also all other threads will not be stucked. Once again: -1/EAGAIN is absolutely legal as well generally and more correct here, that's what I am saying. SY, Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030409123431.GD33144>