On Thu, 14 Oct 2004 14:11:40 +0000, Bill Studenmund wrote:

> On Thu, Oct 14, 2004 at 07:38:34AM -0400, Allen Briggs wrote:
>> FWIW, I agree with this, although the manual should be explicit that
>> it doesn't match what you might expect if you're familiar with the
>> semantics of FIONREAD.  With no prior art, it would make the most
>> sense to have:
>> 
>> 	FIONREAD int
>> 		Get the number of bytes that are immediately available
>> 		for reading.
>> 
>> 	FIONWRITE int
>> 		Get the number of bytes that are immediately available
>> 		for writing.
>> 
>> i.e., for non-blocking applications, I think this is exactly what I'd
>> want--how many bytes can I write in one shot without getting back either
>> a short write or EAGAIN.
> 
> The problem is that this value is very difficult to promise, and in some 
> cases difficult to calculate.

I hope such questions are not too stupid:

would such FIONWRITE/FIONSPACE be equivalent to the functionality
already provided by kqueue/kevent with the EVFILT_WRITE filter? From
the manual page:

     EVFILT_WRITE   Takes a descriptor as the identifier, and returns
		    whenever it is possible to write to the
		    descriptor.  For sockets, pipes, fifos, and ttys,
		    data will contain the amount of space remaining in
		    the write buffer.  The filter will set EV_EOF when
		    the reader disconnects, and for the fifo case,
		    this may be cleared by use of EV_CLEAR.  Note that
		    this filter is not supported for vnodes.

If it would, then: 1) is duplication of this functionality needed?  
2) why not do the same thing with respect to network buffer exhaustion etc.
problems as this kfilter does (whatever it does - I haven't looked)?

Bye	Pavel