Do epoll / other c10k solutions address I/O-bound situations?

I thought that most of these solutions deal with CPU-bound and sometimes RAM-bound situations -- i.e. they fix spending too much time spinning the CPU in various ways waiting for I/O, or too many threads at once taking up too much RAM.

epoll() is for IO-bound situations. You write your program using an event model, where the events are IO related (you select events based upon file descriptors being ready for reading and/or writing) which (in my opinion) make for easy programming of network based daemons ( http://boston.conman.org/2007/03/08.1 ).

The general method appears to be, write the program using an event model, then create a thread per CPU, which each thread waiting on epoll() (timeouts optional).

Maybe I'm missing something -- if you're I/O-bound why would it matter whether you use epoll() vs poll() other than CPU usage?

From what I understand (and how I've used it in my work), one uses epoll() specifically because they're NOT I/O-bound and so need to come up with strategies for using the minimum amount of CPU and RAM per simultaneous I/O so as to avoid becoming CPU- or RAM- bound.

Hence my original point -- if one is I/O-bound while using poll(), it doesn't really matter whether the CPU is spinning on that or epoll(), since I/O won't happen any faster.

I just found epoll() much easier to work with than select() (been there, done that, rather not go back to it) or poll(), and the fact that you avoid scanning an array upon return.

> The general method appears to be, write the program using an event model, then create a thread per CPU, which each thread waiting on epoll() (timeouts optional).

Alternative arrangement is to have a single IO thread that deals exclusively with getting data off the wire and multiple "worker" threads that handle the actual processing. I like this model better, because it provides cleaner logic separation, run-time threading control and it has several other advantages. Though "your experience may vary".