4 ms·
Hey ajross, do you know any good sources for reading up on different I/O paradigms? It's one of those things that I've read about different methods here and th
by hurt 17y ago
Hey ajross, do you know any good sources for reading up on different I/O paradigms?
It's one of those things that I've read about different methods here and there, but I've never come across one good source that compared and contrasted the various techniques.
The short answer may very well be no, since it somewhat depends on the programming language one chooses to use. As you'd likely handle I/O differently in something like Haskell, versus python. Anyway, I'm just curious Thanks.
- silentbicycle 17y agoFWIW, the C10K Problem page (http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html) compares various approaches to handling tens of thousands of simultaneous clients. It's from 2006, but is a good overview of well-understood techniques. Also, some observations on server design from Jeff Darcy (http://pl.atyp.us/content/tech/servers.html http://pl.atyp.us/content/tech/servers.html).
- ajross 17y agoArgh... was just googling to find that link when you posted it. But yeah: this is the first attempt in the modern world to sit down and come up with a real guide to high performance I/O. Most of it is still relevant, though it was written before scary parallel SMP became common (8-way is routine for a server these days).
- silentbicycle 17y agoYeah. If you have any other links, please share. It wasn't too long ago when people were excited about fork-for-each-connection servers, though at least half of it was "OMG Unix system calls from Ruby" from people who probably don't know C. (That "* is Unix" meme.) Simpler approaches are good enough sometimes, though. There are plenty of services that won't ever need to handle more than a couple simultaneous connections, and that way you don't need to bother with asynchronous IO.
- hurt 17y agoThanks to you and ajross, this really helps.