Being told that no one uses select() for I/O multiplexing: 2 minutes
A commenter known as GodsKid asks:
[Just found your blog, from Drunken's...] Ok - so what DOES one use instead of select() ? [I just wrote one of those, with nothing to model it after.]
It's been a few weeks since this infamous interview, but I think I can recall what he suggested.
If you go the traditional
select() route, a single thread uses that system call to wait on a group of sockets until one of them becomes ready to read. He said the better way to handle this is to have a single thread block on accept(). Once accept() returns a socket for an incoming connection, assign it to a member of a thread pool. The thread that gets that socket is responsible for reading and writing from it over the lifetime of the connection.In doing some further reading, I learned that the thread pool approach has the disadvantage of requiring lots of memory for the case where the thread pool becomes very large. I also found an interesting blog posting that says a better way to go is non-blocking I/O. He writes from the Java NIO perspective, but if you're a UNIX programmer, you can get there with the POSIX asynchronous I/O functions.
Hope that helps.
