From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 05:34:34 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D5BE37B401; Wed, 9 Apr 2003 05:34:34 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E9443F85; Wed, 9 Apr 2003 05:34:32 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h39CYVDR033760; Wed, 9 Apr 2003 16:34:31 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h39CYVmw033759; Wed, 9 Apr 2003 16:34:31 +0400 (MSD) Date: Wed, 9 Apr 2003 16:34:31 +0400 From: Alex Semenyaka To: Terry Lambert Message-ID: <20030409123431.GD33144@snark.ratmir.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E940993.FBAFFD70@mindspring.com> User-Agent: Mutt/1.5.4i cc: "Andrey A. Chernov" cc: Yar Tikhiy cc: Alex Semenyaka cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2003 12:34:34 -0000 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