--nextPart1443502.BqPbv0Ht9g
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 20 October 2004 17:06, Bill Studenmund wrote:
> On Tue, Oct 19, 2004 at 08:46:08PM -0500, David Young wrote:
> > I can see the virtue in an API that you can re-use with ttys, files,
> > but a trivial modification to the socket API won't do?  I believe it was
> > Charles Hannum who suggested on another venue that you could add a flag
> > to sendto(2) that has the desired semantics---MSG_ATOMIC?
>
> No.
>
> Those aren't the semantics I desire. Those are the semantics that Charles
> thinks I should desire and that should do what I want. I do not think they
> will.

This problem has been ill-defined from the start, as can be seen by the num=
ber=20
of times you've had to supply additional information both here and on ICB.

You've stated two actual concerns, AFAICT:

1) You don't want to fill the queue with a particular type of request if=20
communication is stalled.  As I pointed out on ICB, since these requests ar=
e=20
acked, this can be solved more than adequately at the application level by=
=20
capping the number of outstanding requests, as is done in many other=20
protocols.

2) You seem to think that it is better to never send a request if there is=
=20
anything in the queue.  This is, AFAICT, a minor optimization given the=20
previous, and does not warrant modifying the OS.

--nextPart1443502.BqPbv0Ht9g
Content-Type: application/pgp-signature

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

iD8DBQBBdqxK5ECq/rI19aIRAjYvAJ0TrO0sarAuToKGSYV3V3f+f5t0gQCdFy5x
M1JZ0DEj0TVMn51ABNMlG6k=
=GS29
-----END PGP SIGNATURE-----

--nextPart1443502.BqPbv0Ht9g--