termios & non-blocking I/O

Daniel Eischen eischen at pcnet1.pcnet.com
Wed Apr 9 08:14:46 PDT 2003


On Wed, 9 Apr 2003, Yar Tikhiy wrote:

> On Tue, Apr 08, 2003 at 10:17:08PM +0400, Andrey A. Chernov wrote:
> > On Tue, Apr 08, 2003 at 20:46:14 +0400, Yar Tikhiy wrote:
> > > While not in disagreement with POSIX[1], such a behaviour has at
> > > least one unwelcome consequence:  If a program has been compiled
> > > with ``-pthread'', the TIME counter won't work on terminal descriptors
> > > that are in blocking mode from the program's point of view -- read(2)
> > > will instantly return 0 on them.  That is because the following
> > > scenario will happen:
> > ...
> > 
> > > Shouldn't both TIME and MIN cases be uniform in returning -1/EAGAIN
> > > on non-blocking descriptors?
> > 
> > It means that libc_r MIN/TIME handling should be fixed to conform POSIX
> > and not general MIN/TIME handling way.
> 
> Not exactly, I'm afraid.  If the system returns 0 from read(), libc_r
> has nothing else to do but to pass this 0 to the application because
> it may be the EOF sign.  Of course, the issue is more complex then I
> outlined, as Bruce Evans has pointed out.  However, why to treat TIME
> differently from MIN in the system?

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.

It shouldn't be a problem with the threadsNG.

-- 
Dan Eischen



More information about the freebsd-arch mailing list