Re: select for UNIX sockets?

[Jesse Pollard <jesse@cats-chateau.net>]

On Tuesday 10 June 2003 09:21, Krzysztof Halasa wrote:
> Timothy Miller <miller@techsource.com> 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.

Ahh no.

The following is from Solaris 2.8 manpage on poll:

     The poll() function supports  regular  files,  terminal  and
     pseudo-terminal  devices,  STREAMS-based  files,  FIFOs  and
     pipes.  The behavior of poll() on elements of fds that refer
     to other types of file is unspecified.

     The poll() function supports sockets.

     A file descriptor for a socket that is listening for connec-
     tions  will indicate that it is ready for reading, once con-
     nections are available.  A file descriptor for a socket that
     is  connecting asynchronously will indicate that it is ready
     for writing, once a connection has been established.

As in: ALWAYS ready to write as soon as a connection is made. It can
still block on a write if the amount to write is larger than the buffer
available. Nothing is said about the AMOUNT that can be written
(though with most FIFOs/pipes the limit is ~ 4K, though not guaranteed
since other writers may fill it between the poll and the write.

The select function (3c):

     The select() function supports regular files,  terminal  and
     pseudo-terminal  devices,  STREAMS-based  files,  FIFOs  and
     pipes. The behavior of select()  on  file  descriptors  that
     refer to other types of file is unspecified.

And the following on it's use on sockets:

     A file descriptor for a socket that is listening for connec-
     tions  will indicate that it is ready for reading, when con-
     nections are available.  A file descriptor for a socket that
     is  connecting asynchronously will indicate that it is ready
     for writing, when a connection has been established.

as in "READY for writing", not that it won't block when you DO write.

(Also "READY for reading", not that it won't block when you DO read.)

You've been lucky to have relatively idle systems or large memory
systems.

I suspect you actually were blocking, just not for very long.