Printable View
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.
Whether you make one call with a 100ms timeout vs. 100 calls with a 1ms timeout is dependent upon your need for timeliness vs. overhead. If you cannot afford a 100ms delay to get some TCP event notification (other than an signal/interrupt), then you need to set a shorter timeout. Each call to select() results in a kernel call, hence context switch. More calls == more overhead. Which approach you use is a design consideration.Quote:
Originally Posted by mjdubois
What does the OS do during the select? Good question, but quite a bit, I think. Eventually it sets a timer and waits for something to happen - the timer expiring, or some event that it is interested in occuring.
What one process does will not affect another process, unless they are blocking on a system-level semaphore or other resource. If I am blocked waiting for select() to return, you can be running select() and not be blocked. Each process has its own memory, registers, time slice, etc. That's why Linux is a multi-tasking system. It can do many things at seemingly the same time (or actually at the same time in a multi-processor system).
Thank you for your quick response. We were using usleep for 1ms originally with non-blocking I/O, but found one call to usleep cost us 20ms (I assume due to the context switching). Would the same be true for the call to select?
A call to usleep should not cost 20ms. 20usec (microseconds) would be more appropriate, unless your system is busy and your application was preempted. Remember, Linux is not a real-time system and scheduling is not always "fair". In any case, usleep() is not necessarily accurate and not really what you would want to use. The interval timer facility (setitimer(), getitimer()) would probably work better for most purposes. That's what I've used in the past when programming socket selects.Quote:
Originally Posted by mjdubois
As for select() overhead, it would be difficult to say, since I don't know what the internal implementation looks like for either select() or usleep(). FWIW, usleep() probably uses an interval timer under the covers. In any case, 20ms seems VERY long to me. A non-blocking system call should only take a few microseconds (or less) unless the process was not scheduled due to system overhead.
You're right; 20 ms does seem to be a long time and I would not have expected this. (By the way, we are using LynxOS). However, when I searched for help on this I found similar posts from other users finding 20 ms also. But because usleep is non-deterministic and waits a minimum of the time specified, we opted to use select instead.
Ok. LynxOS is not Linux, but it does have kernel support for Linux executables and such. It may be that they don't really support usleep(), at least deterministically. Sorry I don't have any LynxOS experience. My real-time system experience was mostly with QNX, which does definitely support deterministic timers.Quote:
Originally Posted by mjdubois