From owner-freebsd-hackers Sun Dec 7 23:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07461 for hackers-outgoing; Sun, 7 Dec 1997 23:10:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07450 for ; Sun, 7 Dec 1997 23:10:23 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA03325; Sun, 7 Dec 1997 23:09:57 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd003322; Sun Dec 7 23:09:51 1997 Date: Sun, 7 Dec 1997 23:07:24 -0800 (PST) From: Julian Elischer To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: Why FIONREAD has no dual for write ? In-Reply-To: <199712061054.LAA25661@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 6 Dec 1997, Luigi Rizzo wrote: > I think I already brought this out but recent discussion on mpegtv > suggests to bring this out again. > > FIONREAD tells you how many bytes you can read before blocking. > > There is no FIONWRITE call (how many bytes you can write before > blocking) which would be nice to have, instead of having to resort to > non-blocking writes. but it could change between the time you do that call and the time that doo the write (you could be sharing a file descriptor, or you could be sharing a device) so you may have to handle the blocking write anyhow. > > And there is no FIOWQUEUED call (or similar name) to tell how many > bytes are queued for I/O on a given descriptor. true do you really thing this is useful? > > The latter could be used e.g. in audio drivers to extract sync > information from the driver itself. Or on sockets/pipes, to decide > whether there is a risk that the pipe runs dry. possibly there might be a more DIRECT way of doing what you want with appropriate device driver. > > Are these only necessary for real-time purposes ? And even in that > case, since pseudo real-time apps are coming out (e.g. audio/video, > driving a CD writer, etc.) wouldn't it be worthwile adding them ? Well, I guess it wouldn't help any programs with aims of being portable. > > Implementation would be rather trivial in many cases (for audio they > are already there under a different name; for sockets it suffices to > check the socket buffer size, > If you can get iti past the censors then I guess it would be ok, but I can imagine a few screams from some quarters.