Date: Sun, 20 Apr 2003 05:14:24 +0400 From: Alex Semenyaka <alexs@ratmir.ru> To: threads@freebsd.org, freebsd-hackers@freebsd.org Cc: Yar Tikhiy <yar@freebsd.org> Subject: Re: termios & non-blocking I/O Message-ID: <20030420011424.GA52428@snark.ratmir.ru> In-Reply-To: <3E94AB82.496681D5@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> <20030409123431.GD33144@snark.ratmir.ru> <3E94AB82.496681D5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030420011424.GA52428>