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

On Mon, Oct 18, 2004 at 10:00:17PM +0200, Pavel Cahyna wrote:
> > The functionality (well FIONSPACE) would be the same. I believe this=20
> > duplication is needed as it is not exact duplication. kevent is, as its=
=20
> > name implies, an event framework. If your application is set up so that=
=20
> > being able to write works as an event, then this filter is perfect. If,=
=20
> > however, the app isn't set up for being able to write =3D=3D an event, =
then=20
> > this filter doesn't help.
>=20
> I must admit that I never wrote any code using kqueue/kevent, but would
> calling kevent(2) with a zero timeout help? If no event is returned, then
> it means that there is no space. Otherwise you use the value of _data_
> just returned.

I really don't think so. The whole point of kqueue is that you've=20
previously set up all the filters. Since I only care about one given=20
socket, I need to see (or not see) only the write filter for it. So that=20
means I need my own kqueue. Thus for what I want to do, each connection=20
needs its own kqueue. That's a huge waste just to find out how much space=
=20
is open on a connection.

Different programs work best differently. For some programs, I think the=20
write filter works best. For mine, however, it does not. Thus FIONWRITE=20
and FIONSPACE.

> > As for your second point, "why not do what this filter does for buffer=
=20
> > exhaustion," well, the filter does nothing. It really is just reporting=
=20
> > how much space is open in the buffer; the text you quote is ignoring al=
l=20
> > the issues I've raised. :-)
>=20
> I suspected it. Maybe doing nothing is enough? If it isn't, shouldn't the
> filter be fixed, too? (If an implementation of FIONSPACE which cares about
> those issues is ever written.) I just think that consistency would be goo=
d.

Doing nothing is fine. My big concern has been over semantics, so that we=
=20
don't promise what we can't deliver.

Take care,

Bill

--bajzpZikUji1w+G9
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBdC+YWz+3JHUci9cRApahAJ0TZ7VyFoX/vEq/oaJzY7+FqlfF1QCbBt61
vdFGdspw7AopA0bovvx2DH4=
=2fNN
-----END PGP SIGNATURE-----

--bajzpZikUji1w+G9--