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

On Sun, Oct 17, 2004 at 06:22:26AM -0500, David Young wrote:
> Sure, but by the time the application that uses FIONSPACE has detected
> resource exhaustion, it has already done a short write.  Recovering from
> that could be a PITA, especially in Bill's app.

Actually, for my app and its protocol, once you start to write, there is
no recovering. The protocol makes use of PDUs, and once you start one, no
other one can be started until that one finishes. So the socket actually=20
is blocking; saves having to retry partial writes. And since the app is=20
multi-threaded, work continues to go on.

> Perhaps FIONSPACE should make a "soft reservation".  That is, if
> FIONSPACE indicates that N bytes can be written to a non-blocking
> descriptor immediately, then an app can expect for write(2) to return
> EAGAIN if it cannot honor the soft reservation, due to buffer exhaustion.
> That is, immediately following a FIONSPACE call, trying to write N or
> fewer bytes should not result in N-1 or fewer bytes actually written.
> You reset the soft reservation by writing to the descriptor or else
> by calling FIONSPACE again.  The name for this alternative should be
> different from FIONSPACE---FIORSPACE?

The problem is that the reservation would need some sort of ID. The=20
problem with your suggestion as-is is that other writes can get injected=20
between the FIONSPACE call and the write(2) which we wanted to get the=20
reserved space. So even though FIONSPACE reported room, the write that we=
=20
wanted to have work won't.

Take care,

Bill

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

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

iD8DBQFBdC1GWz+3JHUci9cRAtEWAJ98yH8h4LOtxlPbGLqtMk7Zu+JFXACgjfY+
jgnFwLDXfEP2/dJIIIXrj9Y=
=o9Ls
-----END PGP SIGNATURE-----

--c3bfwLpm8qysLVxt--