--VUDLurXRWRKrGuMn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 13, 2004 at 05:56:09PM -0700, cgd@broadcom.com wrote:
> At Wed, 13 Oct 2004 23:12:58 +0000 (UTC), "Bill Studenmund" wrote:
> > This ioctl is like FIONREAD, except instead of looking at the read queu=
e,=20
> > it looks at how many bytes are in the write queue.
> >=20
> > The semantic for the value is that it returns the number of bytes writt=
en=20
> > to the file descriptor that have not been "sent". If someone can come u=
p=20
> > with a better description, I'm all ears. :-)
> >
> > I want this call because I have an application which needs to do
> > scheduling flow control in userland. I can't just depend on a non-block=
ing
> > socket as the protocol I'm using deals with requests (protocol blocks or
> > PDUs, etc.). So once you start sending a request, you have to finish it.
>=20
> Why is "number of bytes which have not yet been 'sent'" the right
> semantics, as opposed to, say, "number of bytes that you can
> immediately write"?
>=20
> The latter would definitely more akin to the write side of FIONREAD,
> as far as I know...

I'm looking at it more from the vantage point of Recv-Q and Send-Q in=20
netstat -A. That's what I went into this thinking I wanted to know.

> (I'm thinking that the notion of "have not been 'sent'" is very, very
> nebulous, and, at least from your description isn't the information
> that you actually want, anyway!)

Like I said, I'm looking at it from a Send-Q point of view.

FIONSPACE has been suggested, which would return how much space is in the=
=20
send buffer. I don't mind also adding that. However I am concerned about=20
returning "how much can be written" as there can be other resource issues=
=20
(global buffer lack) that mean that even though the send queue has space,=
=20
a write still wouldn't succeed.

Turns out that, as best I can tell, vxworks already has a FIONWRITE with=20
the semantics this patch has.

Take care,

Bill

--VUDLurXRWRKrGuMn
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBbdy4Wz+3JHUci9cRAjJoAJ0SIQQizmjgZRevhcZdGOt1+oVsAgCePdg6
svztvbIaWy2SRogysJm/jgY=
=Uf+1
-----END PGP SIGNATURE-----

--VUDLurXRWRKrGuMn--