At 04:38 PM 10/13/2004, Jason Thorpe wrote:

>On Oct 13, 2004, at 4:11 PM, Bill Studenmund wrote:
>
>>I want this call because I have an application which needs to do
>>scheduling flow control in userland. I can't just depend on a non-blocking
>>socket as the protocol I'm using deals with requests (protocol blocks or
>>PDUs, etc.). So once you start sending a request, you have to finish it.
>>For some things, I'd like to be able to make a decision about sending
>>before I commit to sending the specific PDU.
>>
>>Thus this ioctl.
>>
>>Thoughts?
>
>I would add a note in the manual page along the lines of "If you want to 
>use this to implement application-level flow control, you need to first 
>know how large the outbound buffer is", e.g. the send buffer on a socket 
>(which you can query with getsockopt(2)).

I strongly disagree.  FIONREAD works with tty, sockets, pipes, and a whole
bunch of other devices.  While sockets have a method to get the output
buffer size, many device drivers don't.  How do you get the output buffer
size of a tty?

I'd rather a different ioctl (since FIONWRITE seems to exist on other
platforms), say FIONSPACE, which return the amount of output that can be
accepted without forcing the writer to block.

In addition, for sockets, adding a SO_ATOMIC/MSG_ATOMIC so you can tell
the socket layer to only send complete messages if it won't block would
be a great addition.


-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.