termios & non-blocking I/O

[Alex Semenyaka]

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