From owner-freebsd-current Tue Apr 17 13:42: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DE75737B42C for ; Tue, 17 Apr 2001 13:41:59 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA32605; Wed, 18 Apr 2001 06:41:33 +1000 Date: Wed, 18 Apr 2001 06:40:38 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Garrett Wollman Cc: "John W. De Boskey" , Current List Subject: Re: FIO* doc added to tty.4 (review) In-Reply-To: <200104171817.OAA13546@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Apr 2001, Garrett Wollman wrote: > < said: > > > ie: FIONREAD will succeed from a backgrounded process, but the > > data read itself with hang (tty driver). > > You are describing a general property of the terminal subsystem, which > any process dealing with terminals needs to be aware of. > > (AFAIK, ioctl(tty, FIONREAD, &n) should set n to zero if the process > is in the background; if it does not that's probably a bug.) It doesn't. However, applications should be prepared to deal with there being no readable data. Success of FIONREAD doesn't guarantee non-blocking of a blocking read in general -- the data may have been read by another process, or there may not be enough data to satisfy the programmed MIN/TIME requirements. > The new POSIX revision group discussed this briefly in the > mailing-list, but the group did not want to innovate in this area. select() and poll() would give the same false positive as FIONREAD, and probably doesn't handle MIN/TIME right. Does POSIX now specify select() and/or poll() precisely enough to show that the current behaviour is wrong? Related bug: ttioctl() doesn't understand all driver ioctls well enough to know which ones should wait until the progress is in the foreground; drivers know even less about background processes. So background processes an do some ioctls that change the device state underneath forground processes. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message