Date: Wed, 9 Apr 2003 11:14:43 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Yar Tikhiy <yar@freebsd.org> Cc: arch@freebsd.org Subject: Re: termios & non-blocking I/O Message-ID: <Pine.GSO.4.10.10304091112330.8642-100000@pcnet1.pcnet.com> In-Reply-To: <20030409113653.GA63770@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304091112330.8642-100000>