I am using recvfrom with UDP and recv with TCP.

Using blocking, what is the difference between calling
select() 100 times with a 1ms timeout
vs calling select() one time with a 100ms timeout?

What exactly does the operating system do during the select?
How expensive is it to repeatedly call select?
Will other processes be able to run while we are blocking?
Thanks for any and all help.

Calling select() more often with shorter times will give your program more often the opportunity to do other things at the cost of some overhead of calling select() and checking for activity on file descriptors more often.

The same things it would do if your program is not running. Since you program a sleeping in select() the OS can forget about your program for the time being... It just has registered the filedescriptors you want the OS to watch for you. When a IP packet for your program arrives, the network interface will issue an hardware interrupt (IRQ). The kernel module (driver) for the network interface gets the raw network data from the packet, passes it to the TCP/IP modules in the the kernel and figures out to which program/process it should go. And it will find out it is your program. The kernel notices your process is sleeping in select(), then checks if the filedescriptor for the incoming packet is in the set of descriptors you gave to select() to watch. If so, the kernel will mark it and return from select(), thus awakening your program.

Sure! UNIX/Linux is a multitasking OS. Your program is asleep in select() so no better time than this to run other processes.

"select()" with *any* timeout == "polling"...
... and Polling as Bad.

Unavoidable sometimes, but seldom ideal.

The best reason to use "select()" is if you're waiting for I/O on any of several sockets and/or file descriptors. If input arrives: you act on it (regardless of which file initiated the input). Otherwise, you block.

If you want to wait for input *and* you want to do work at the same time, use threads.

IMHO .. PSM

Good point. Quoting man select_tut:I don't agree with that. I'd say: never use threads unless...

Coding a server program that needs to handle multiple connections (sockets) simultaneously, select() is the only feasible way to do it sequentially (i.e. within one process, one thread) which is arguably a very elegant way.

Another way is to fork off a seperate process for each connection.

Threads is third way to handle multiple connection at the same time. Threads may probably the way to squeeze out the last bits of performance from the program. But to get that last bit of performance out of the "threads-method" you really need 'to do it right'. And coding a threaded program can be very difficult to do right. It is the most error-prone way. You really need to know what you're doing in order not to create hard-to-find-bugs, security-holes and race conditions.

When you got all that right, would you still have that last bit of performance gain from it? Maybe, but is it worth the trouble?

There are people much more knowledgable than me suggesting the computing world may even be better of without threads alltogether:
Threads considered harmful
The problem with threads

I recently developed an thread that uses select() with a timeout. If activity is detected, then I handle the incoming message(s) from the socket. If activity is detected and/or the timeout period expires, I also do something else.

The timeout period chosen was based on how often I should do the "something else". Receiving from the socket was an ancillary task. By using the select(), I was able to "kill two birds with one stone", and more importantly control how often the "something else" is done.

I'm certain that there are other ways to accomplish what I have done, but what I did is not wrong, or bad.

P.S. I rarely expect messages from the socket, so in essence the select() is being used as a timer.