Re: select for UNIX sockets?

[Edgar Toernig]

Krzysztof Halasa wrote:
> 
> Timothy Miller <[e-mail]> writes:
> 
> > 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.
> 
> This is all true in general but in this particular case of unix datagram
> sockets select (poll) is just buggy.

Do you want to install a magic crystal ball in the kernel? :-)

For select to properly block on write it has to know the destination of
the write.  For unconnected sockets you haven't told the destination.
There's know way for the kernel to know at select time which receiver
to check for free space.

You were talking about a "send queue".  I guess you think it should
work like: if destination has enough room move data to destination
else queue it in the send queue.  Then select would check whether the
*send queue* has enough space for another packet.  But that would mean
that a single slow receiver would block all others.  I.e. /tmp/a is
slow; you fill the queue; select blocks even when you actually want to
send to /tmp/b which has plenty of space.

Ciao, ET.