Re: select for UNIX sockets?

Timothy Miller
2003-06-10T13:08:27Z

Krzysztof Halasa wrote:
> "David Schwartz" <davids@webmaster.com> writes:

>> The kernel does not remember that you got a write hit on 'select'
>>and use
>>it to somehow ensure that your next 'write' doesn't block. A 'write' hit
>>from 'select' is just a hint and not an absolute guarantee that whatever
>>'write' operation you happen to choose to do won't block.
>
>
> A "write" hit from select() is not a hit - it's exactly nothing and this
> is the problem.
> Have you at least looked at the actual code? unix_dgram_sendmsg() and
> datagram_poll()?

I think the issue here is not what it means when select() returns but
what it means when it DOESN'T return (well, blocks).

In my understanding, one of select()'s purposes is to keep processes
from having to busy-wait, burning CPU for nothing. Your guarantee with
select() is that if it blocks, then the write target(s) definately
cannot accept data. The inverse is not true, although the inverse is
very likely: if select() does not block, then it's extremely likely
that the target can accept SOME data. But it it certainly can't accept
ALL data you want to give it if you want to give it a lot of data.

If you were to use blocking writes, and you sent too much data, then you
would block. If you were to use non-blocking writes, then the socket
would take as much data as it could, then return from write() with an
indication of how much data actually got sent. Then you call select()
again so as to wait for your next opportunity to send some more of your
data.

It may be that some operating systems have large or expandable queues
for UNIX sockets. As a result, you have been able to send a lot of data
with a blocking write without it blocking. I can see how it would be an
advantage to function that way, up to a certain point, after which you
start eating too much memory for your queue. However, what you have
experienced is not universally guaranteed behavior. What Linux does is
canonically correct; it's just a variant that you're not used to. If
you were to change your approach to fit the standard, then you would get
more consistent behavior across multiple platforms.

Up to this point, I believe you have been riding on luck, not guaranteed
behavior.