Here is the scenario, one server handling multiple clients using select() few of the fds are very active(there are very much data coming on few) while other are normal active. Then will other fds starve, as select will be busy serving very active fds ?

Here is the scenario, one server handling multiple clients using select() few of the fds are very active(there are very much data coming on few) while other are normal active. Then will other fds starve, as select will be busy serving very active fds ?

• c
• network-programming
• select
• file-descriptor

• 4 What do you mean by "select will be busy"? After you call select you get a set of ready FDs. It is up to you which one you handle first. You can handle all available FDs before you call select again. – Gerhardh Commented 17 hours ago
• 2 The select function returns a list of all descriptors that are "ready" (e.g. for reading it means that a read or recv call will not immediately block). There's no "starvation" from that point of view. The main problem is your applications processing of the "ready" descriptors, which will affect the polling interval (how often select is called). – Some programmer dude Commented 17 hours ago
• What I meant was say fd x, has lots of data coming to read while other fds not getting enough chance to read data. What I understand from your answer is, its not select who will be busy but individual client application will be busy in read while will other fds starve to read data. right ? – anand Commented 17 hours ago
• Please show an example of what you are talking about. Now you mentiond different client applications. That does not make much sense. Different applications do not share the same call to select. One client calls select once at a time. Do you mean totally different applications using completely unrelated file descriptors with different level of CPU utilization and amount of generated data? – Gerhardh Commented 14 hours ago
• 1 @anand, "What I meant was say fd x, has lots of data coming to read while other fds not getting enough chance to read data" -- reading incoming data is something the program calling select() does after determining which FDs are ready. Yes, it is possible for an application to be overwhelmed by more incoming data than it can handle in a timely manner, but that's not a situation caused by select(). Indeed, select(), used appropriately, often improves an application's bandwidth vs the old-style approach of assigning a child process to each logical data stream. – John Bollinger Commented 12 hours ago

1 Answer 1

can starvation happen due to select serving few fd while other fd starve?

No, select() reports on all ready file descriptors (from the specified interest sets) at each return. It is the caller's responsibility to service them all to avoid starvation, and that is facilitated by select() -- the program can avoid both (i) blocking trying to read or write file descriptors that are unready and (ii) wasting time on non-blocking I/O requests that are unproductive. Ordinarily, the program would service all ready file descriptors before select()ing again. Details vary.

From comments:

What I meant was say fd x, has lots of data coming to read while other fds not getting enough chance to read data.

It is to a large extent within the control of the program that is multiplexing I/O with the help of select() to ensure that all clients are serviced. There is a variety of ways it can approach that problem, and facilitating that is the point of using select() in the first place.

Nevertheless, every machine has limits on its I/O and processing capabilities. Even with effective use of select(), it is possible for a program to be overwhelmed with more data and processing requests than it can keep up with. In that case, which streams it fails to service in a timely manner is largely a matter of the program's implementation details and the relevant communication patterns. It is not necessarily lower-volume streams.