Performance of select() in multiple threads (Linux)

Asked Dec 30 '11 at 07:43

Active Dec 30 '11 at 07:43

Viewed 437 times

According to CURL and libev maintainers, select gets really bogged down after about 100 or so file descriptors. Could I extend select to about 1000 or so file descriptors if I split my file descriptors across multiple threads? or would there be so many inefficiencies that it's not worth doing?

I don't need 10,000 connections (who does?). Mucking with epoll or whatever is not desired. I just need about 1000 connections or so to not bog down a dual-core 3Ghz. Assuming that select (and processing for select) are the largest bottlenecks in the software.

asked Dec 30 '11 at 07:43

unixman83

9,421
10
68
102

Why not test the different configurations, and do some measurements before you decide? – Some programmer dude Dec 30 '11 at 07:55
You could use `libev` and let it deal with select/epoll. – jfs Dec 30 '11 at 11:57
@JoachimPileborg I was hoping that someone had already tested multithreaded `select` and could share. That's why I posted. – unixman83 Dec 31 '11 at 01:50

Performance of select() in multiple threads (Linux)

0 Answers0