From owner-freebsd-hackers Thu Feb 6 12:01:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA00800 for hackers-outgoing; Thu, 6 Feb 1997 12:01:09 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA00788 for ; Thu, 6 Feb 1997 12:01:04 -0800 (PST) Received: (qmail 1421 invoked by uid 5); 6 Feb 1997 20:01:01 -0000 MBOX-Line: From jb@freebsd1.cimlogic.com.au Thu Feb 6 13:38:00 1997 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id NAA04044; Thu, 6 Feb 1997 13:38:00 +1100 (EST) From: John Birrell Message-Id: <199702060238.NAA04044@freebsd1.cimlogic.com.au> Subject: Re: fcntl, F_SETFL, O_NONBLOCK & /dev/null To: bde@zeta.org.au (Bruce Evans) Date: Thu, 6 Feb 1997 13:37:59 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199702060208.NAA32068@godzilla.zeta.org.au> from Bruce Evans at "Feb 6, 97 01:08:24 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > >I can open /dev/null with O_NONBLOCK. If I open /dev/null without > >O_NONBLOCK and then try to fcntl F_SETFL to change the file descriptor > >to non-blocking, I get ENODEV returned. Can someone tell me why? > > fcntl(fd, F_SETFL, O_NONBLOCK) is translated to an FIONBIO ioctl, and > the device driver for /dev/null doesn't support this ioctl. None of > the memory devices support it. > > Another problem with the translation is that the flag is supposed to > be per-file, but if the FIONBIO ioctl actually does anything, then > the flag is sort of per device - a per-file flag is kept in all cases, > but it may be inconsistent with the device state. > > One way to fix this is to remove the FIONBIO calls from fcntl(). > This isn't quite right, since it should be possible for drivers to reject > O_NONBLOCK (or maybe !O_NONBLOCK). However, in practice most drivers > are too stupid to check for O_NONBLOCK in their open routine and too > stupid to support FIONBIO in their ioctl routine. This results in the > stupid behaviour that you observed. Thanks for the info. This means that libc_r will always have difficulty dealing with such devices. The library expects to be given non-blocking behaviour if (when) it asks for it. So the best I can do is open() the device with O_NONBLOCK and hope that the driver obeys. If not, an unexpected wait will occur, without another thread being scheduled in the meantime. Hmmm, yet another reason for kernel threads... > > Bruce > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au; jb@netbsd.org 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137