termios & non-blocking I/O

[Terry Lambert]

Daniel Eischen wrote:
> As Bruce pointed out, libc_r correctly doesn't go near TIME/MIN
> handling.  This is a known problem when using libc_r and has
> been raised in the past.  It's just too messy for libc_r to
> try and deal with this.

Further, case #1 (POSIX.1 case "A") *can not be made rational* in
the presence of non-blocking I/O, becaue it's not possible for the
caller to distinguish a short read in excess of 1 character as a
result of NBIO vs. a short read as a result of the inter-character
timer expiring.

Case #2 (POSIX.a case "B") _requires_ a non-negative return code
for a short read which is short as a result of NBIO, since *some*
characters are transferred, and that's the only way to guarantee
that the number of characters transferred is recorded somewhere.
In the degenerate case the original poster was complaining about
returning "0", the original poster failed to test with a buffer
with some non-zero number of characters N, such that 0 < N < MIN.


> It shouldn't be a problem with the threadsNG.

Nope.

It shouldn't be a problem in general, except for case #3 (POSIX.1
case "C"), which is a bounded read of some number of characters N,
where MIN < N < number_requested_by_read_cahracter_count_parameter.

Case #4 (POSIX.1 case "D") should be replaced in any code that
links against a threads library with a "listener thread" with a
blocking read for 1 character, which then dispatches to refactored
code that implements the "read return value > 0" code path.  This
is because a for(;;) loop in a single thread of a threaded program
is bad news for the threads scheduler, since it's "always" in the
ready-to-run state.

See other posting for POSIX.1 lawyering and technical justification.

PS: I agree with Daniel: this is not worth implementing in libc_r
at this point, but if someone wants it, they should submit patches.

-- Terry