From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 18:14:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31B9837B401; Sat, 19 Apr 2003 18:14:36 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC35143FE1; Sat, 19 Apr 2003 18:14:32 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1ERC2052447; Sun, 20 Apr 2003 05:14:27 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1EOrL052446; Sun, 20 Apr 2003 05:14:25 +0400 (MSD) Date: Sun, 20 Apr 2003 05:14:24 +0400 From: Alex Semenyaka To: threads@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20030420011424.GA52428@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> <20030409123431.GD33144@snark.ratmir.ru> <3E94AB82.496681D5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E94AB82.496681D5@mindspring.com> User-Agent: Mutt/1.5.4i cc: "Andrey A. Chernov" cc: Yar Tikhiy Subject: Re: termios & non-blocking I/O X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 01:14:36 -0000 Hi! On Wed, Apr 09, 2003 at 04:23:46PM -0700, Terry Lambert wrote: >> 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? > Consistent with what? With each other, see: > The cases are: > > MIN TIME > 1) >0 >0 Interbyte timer; after 1 byte received, timer > is started; if MIN bytes received before timer > is statisfied, return. If another byte is > received, timer is reset; if timer expires, > read is satisfied. > 2) >0 =0 Pending read is not satisfied until MIN bytes > received. > 3) =0 >0 NOT interbyte timer; read is satisfied on a > single byte received or timer expired. > 4) =0 =0 Polling read; available bytes up to number of > requested bytes is returned, and read is always > satisfied. The cases 2) and 3) should be consistent when there is no input data. Now thay are not. > unacceptable. I think it is impossible to implement case #1 correctly > with NBIO enabled, and would convert it to case #4, and implement the > TIME in user space in libc_r. Probably you are right, but that was not the subject of the discussion. > Case #2 is still not correctly handled at all by your proposed change; > libc_r work is required to avoid stalling until input is present; the > correct return on NBIO is pretty obviously "EAGAIN,-1"; HOWEVER, you > may have received *some* input data, but not MIN worth of input data; > returning some number < MIN violates the interface contract; so does > losing the data. That's right as well, of course. Let me remind you that we are discussing the case when there is no input data at all. > Case #3 is a full read timer for one byte; also not correctly handled > in the face of the proposed change. For a TIME=100, we are talking > about stalling all threads for 100 seconds; the correct return is You just left the rest empty, unfortunatelly. But the WHOLE SUBJECT of the discussion is HERE, and my idea is that the correct return is -1/EAGAIN if there is no data. > Case #4 is polling I/O; it's trivial to implement in libc_r. Sure. > Rule of thumb: If it adds latency, which is always annoying; if > it can add an arbitray number of seconds of latency, it's > unacceptable. I never, never, NEVER suggest to add the latency or to block the process in the kernel or something like this. I understand perfectly why is not acceptable. In several letters I wrote my point. Here it is: in the case TIME>0, MIN=0 we in non-blocking mode in the absence of data we should return immidiately, without any blocking (as now, just perfect), but with -1/EAGAIN instead of 0 (as we do now). Because of that 0 we cannot distinguish the legal EOF and just "no data yet" case behind the libc_r. That's it. >> 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. > The problem with this is case #2 with some number of characters less > than MIN. For example, let us propose a MIN of 10, with 3 characters Well it is _another_ problem. The originator had no questions about incomptele block of data for the MIN>0 and waiting data case. It was ok with him. He told about the case MIN=0, TIME>0, no data, non-clocking mode. It is incorrect to return 0 in this case, told he. And I agree with him. ##1 TIME>0 I argue that this is impossible to implement > in the presence of NBIO, since you can not > return both the value of the short read, and > the fact that the timer would result in a > block, simultaneously. Best approach is to > cause an error, EAGAIN,-1. Right! You see? Exactly our point! But NOW it returns just 0. Should be fixed, I think, shouldn't it? :) SY, Alex