Subject: Re: FIONWRITE proposal
To: Matt Thomas <matt@3am-software.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/13/2004 19:15:13
--5Mfx4RzfBqgnTE/w
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 13, 2004 at 06:23:40PM -0700, Matt Thomas wrote:
> At 04:38 PM 10/13/2004, Jason Thorpe wrote:
>=20
> >I would add a note in the manual page along the lines of "If you want to=
=20
> >use this to implement application-level flow control, you need to first=
=20
> >know how large the outbound buffer is", e.g. the send buffer on a socket=
=20
> >(which you can query with getsockopt(2)).
>=20
> I strongly disagree.  FIONREAD works with tty, sockets, pipes, and a whole
> bunch of other devices.  While sockets have a method to get the output
> buffer size, many device drivers don't.  How do you get the output buffer
> size of a tty?

I'm not sure, but there is the TIOCOUTQ call which does the exact same=20
thing as this call. i.e. it doesn't tell you how much you can write, but=20
it tells you how many bytes haven't been sent.

> I'd rather a different ioctl (since FIONWRITE seems to exist on other
> platforms), say FIONSPACE, which return the amount of output that can be
> accepted without forcing the writer to block.

As I said in another message, I wouldn't mind having that call too, though=
=20
that one has questionable semantics for a file.

> In addition, for sockets, adding a SO_ATOMIC/MSG_ATOMIC so you can tell
> the socket layer to only send complete messages if it won't block would
> be a great addition.

While it would, it wouldn't help my application.

Take care,

Bill

--5Mfx4RzfBqgnTE/w
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBbeExWz+3JHUci9cRAv4DAJ4iI1sn/t6zXvEapMCzA74lDaRFowCeIf+u
VTazK8MkF5rkDXv3Aa6gFqA=
=rYOa
-----END PGP SIGNATURE-----

--5Mfx4RzfBqgnTE/w--