Subject: Re: FIONWRITE proposal
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-kern
Date: 10/17/2004 06:22:26
On Sat, Oct 16, 2004 at 11:54:27AM -0400, Greg A. Woods wrote:
> [ 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).

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.

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?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933