Question

So I totally lost it when someone showed me some code using select() like:

FD_ZERO(&readfds);
FD_SET(socket,&readfds);
FD_SET(0,&readfds);
.......// bind() and listen(),regular stuff
// Before select(),this guy cleared readfds to null and sort of start all over again
FD_ZERO(&readfds);// Behold,this is exactly the line confusing myself
FD_SET(socket,&readfds);
// select will be called in the future within a infinite loop 

So basically saying what FD_ZERO after bind and listen is clear previous contents for some reason and insert socket file descriptor to fd set again.Meanwhile,in fd set,the 0 descriptor(standard input) apparently disappeared.

Could anyone explain this whole thing? I don’t feel like this is correct but i cant really figure it out. Maybe setting up some specific fd set all over again is a practical mechanism…

I thought bind() and listen() could modify fd set in some sort of manner.I set up a couple of breaking points and examine the outputs.Consequently,fd set did not change at all.

UPDATE:

What really confuses me is the second FD_ZERO(&readfds).
Obviously the first one is like clearing rusty stuff in the buffer. On each iteration,we have to clear fdset to default for the future. I just dont understand the second one. Either it is a wrong one or it wont hurt at any rate.

Answer 1

Not sure where your confusion lies, but here’s an explanation.

An fdset is a bitmask of file descriptors indexed from zero (technically, I don’t think it has to be a bitmask but any other implementation would be … strange).

So an fdset may be something like:

              Byte 0                              Byte 1
+---+---+---+---+---+---+---+---+ +---+---+----+----+----+----+----+----+
|fd0|fd1|fd2|fd3|fd4|fd5|fd6|fd7| |fd8|fd9|fd10|fd11|fd12|fd13|fd14|fd15|
+---+---+---+---+---+---+---+---+ +---+---+----+----+----+----+----+----+

The idea is that you set the bit for a given fd (file descriptor) if you’re interested in it. If you’re not interested in it, you leave the bit clear.

FD_ZERO will clear all bits, which is a good starting point. Then the two FD_SET calls will set the bits for fd0 (standard input) and fd<socket>.

Then, a select call using that fdset would return if either there was action on standard input or action on the socket (the type of action would depend on which parameter position you used when passing the fdset to select. Passing it as the read fdset means that you’ll return if either you can read the socket or something has shown up on standard input (such as you using the keyboard).

This may well be the useful in the code for a “chat” application since it would wait on input from either you or your friend at the other end.

The reason why you have to re-zero and re-set the bits in an fdset is because select itself modifies the set to indicate what fd (or fds) it detected the action on.

Example: if something came in via the socket and nothing via standard input, the fdset would be modified by select to only have that bit set. That way you can use FD_ISSET to detect which fds you should look at.

---

If, as you seem to indicate in comments, there are no select calls (or other calls using readfds) between the two FD_ZERO()/FD_SET() sequences then, yes, it appears that the first is unnecessary, since the information will be overwritten by the second.

Without seeing the full code, or the architectural design documents 🙂 , it’s hard to tell.