Subject: Re: FIONWRITE proposal
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: David Young <firstname.lastname@example.org>
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?
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933