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/19/2004 20:46:08
On Mon, Oct 18, 2004 at 01:53:26PM -0700, Bill Studenmund wrote:
> 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 
> is blocking; saves having to retry partial writes. And since the app is 
> 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 
> problem with your suggestion as-is is that other writes can get injected 
> between the FIONSPACE call and the write(2) which we wanted to get the 
> reserved space. So even though FIONSPACE reported room, the write that we 
> wanted to have work won't.

I had assumed you would do the ioctl and write atomically.  I don't see
how the other discussed ioctls avoid this problem.

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?

Dave

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