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