[ On Wednesday, October 13, 2004 at 18:56:08 (-0700), Bill Studenmund wrote: ]
> Subject: Re: FIONWRITE proposal
>
> 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 
> send buffer.

Well this alternative (FIONSPACE) has the advantage that you don't need
to know how big the buffer is to make use of it, and also if you know
you haven't written anything yet (and that nobody else has the same
device/socket open :-) then you can also use FIONSPACE to find out how
big the buffer is, and thus also to effectively implement FIONREAD in
the way you originally proposed it (i.e. to find out how much data
that's been written has not yet been "sent").

> However I am concerned about 
> returning "how much can be written" as there can be other resource issues 
> (global buffer lack) that mean that even though the send queue has space, 
> a write still wouldn't succeed.

That is not be a concern at this level.

The meta-level issues of global resources are system tuning issues.  The
individual applications should not be concerned with such things (though
of course they should be prepared to handle any errors that might result
from overall system resource exhaustion).

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>