Tuesday, September 11, 2007

2am Answers a Programming Question

In one of my prior posts, I recalled an experience with an obnoxious interviewer:
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.
blog comments powered by Disqus