Ok, I''m learning about the select() function. There''s one thing I''m unclear on. Let''s say I setup a few sockets to read from with FD_SET() and call select(). Ok, I know select() will block until at least one of those sockets are ready to read from. So, select() returns, and I check my descriptor list to see which sockets to read from. Now, here''s my question. I call recv() to read from one of the sockets. Will recv() get the number of bytes that it is capable of getting RIGHT NOW, and return immediately? In other words, since select() told me this socket was ready to read from, it should not block at all. I realize recv() might not get all the bytes I''m waiting for, but it will ALWAYS return immediately with some quantity of bytes and not block, correct?

Quoting MSDN:

BEGIN QUOTE
The parameter readfds identifies the sockets that are to be checked for readability. If the socket is currently in the listen state, it will be marked as readable if an incoming connection request has been received such that an accept is guaranteed to complete without blocking. For other sockets, readability means that queued data is available for reading such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not to block.
END QUOTE

Now, it appears they will not block.

It is interesting to note that Winsock has made the select() paradigm externally compatible with Berkeley sockets, but the internal representation is entirely different.

Windsock appears to use an array of sockets with a number defining the number of sockets in the array. I think Berkeley uses a bit field. Does anyone know the underlying mechanics of the Berkeley implementation?

But apparently writes using send() may block.

How do we avoid this?

Have you checked out the Winsock faq? There might be something there that explains the contrasts between Winsock and Berkeley sockets.

Another useful site I''ve found on internet programming belongs to Ugo Varetto. He provides a straight forward approach that covers a lot of ground without getting stuck in any one spot. He also does a good job of contrasting Win32 and Unix and provides a sample of some cross platform socket utilizing code.