question about the "fd_set *writefds" parameter in the select() statement

As most of you are aware, this is the prototype of the select statement (acc to man pages):

Code:

---

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
          struct timeval *timeout);

---

I know what to use the readfds parameter for: with this one you can see if data was written to one of your sockets. On the other hand, the writefds page that I found, states that this is to see "if any of the sockets is ready to send() data to". But what does this mean? In Windows Sockets Network Programming by Quin and Shute it says that this detects either the connected or the writable state. What is the point of this? Is it simply to check whether a socket still has a connection to a connected client and test whether is has any use writing something to that socket?

So: what does one normally use writefds for?

Yep. It's pretty much an "are you listening" check. If they aren't, don't waste time sending them anything. You may not necessarily want to close their connection if they aren't ready for writing, but you could.


Quzah.

Ok, clear, thanx. In the meantime I also learned that write() and send() functions can block if your client cannot keep up. readfds detects this.

Quote:

---

Originally Posted by django

Ok, clear, thanx. In the meantime I also learned that write() and send() functions can block if your client cannot keep up. readfds detects this.

---

You actually want them to block if the client is falling behind... otherwise you lose data.

Quote:

---

Originally Posted by CommonTater

You actually want them to block if the client is falling behind... otherwise you lose data.

---

That isn't entirely true. Blocking sockets are okay for applications where you can't proceed without the data, and you can't or shouldn't do anything in the mean time. But depending on the protocol (TCP, UDP, ICMP, etc), you won't necessarily lose data in a non-blocking implementation.

UDP is an unordered protocol, and will happily drop packets if you don't read them in time, since it doesn't care about reliability and sequencing. TCP, on the other hand, does care. TCP guarantees that packets can be reassembled in correct order. The receiving end of the TCP layer will communicate to the other end that it can't take any more data now, so the send on the other end will either block in blocking mode, or report "not ready" in non-blocking mode, so that packets aren't dropped.

True enough... but I was thinking that in multithreaded applications letting it block for a few milliseconds is anything but disastrous when the alternative is data loss...