synthetix

I didn't have to do this because the machine is being queried via the serial port constantly. So, I just passed NULL as the last argument to select(). From what I can tell, this effectively throttles the reads off the serial port based on the speed that the remote machine is sending queries. And since it's running in its own thread, this doesn't tie up the main thread, which is constantly checking variables updated from the serial port reader thread (via a loop) and performing the main program functions.

itCbitC

Reason to have a timeout is to prevent the select from blocking otherwise it'll just sit there and wait for input exactly like the call below:
Is your application doing anything else besides reading from that serial port? Are there many ports to read from?
The power of select() is in its ability to poll each file descriptor in turn, waiting for an event or else timing out.

synthetix

Yeah, it's taking that input and using it to decide what action to take elsewhere in the program. That's why I put it in its own thread. And I don't have a timeout set because the serial port is being read at a constant rate. If there's no serial input, there's nothing the program can do anyway. And if it does happen to hang up, it won't cause the entire program to stop because it's a separate thread. Although now that I think about it, I may just assign a timeout to it anyway "just in case." Seems like it would be a good coding practice, if nothing else.

I did make a variant of this program that does absolutely nothing but send and receive serial port commands. Now, with this one I had to assign a timeout value to select() because the flow of data was not constant. It was a program I wrote to check for proper operation of the first program (this time server side instead of client side). Once commands are sent, the client only responds once, hence complete lockup (blocking) unless you timeout select().