Threading flames

Thanks to Ned Batchelder for pointing out the “discussion” about the pros and cons of multi-threaded programming over on the SQLite newsgroup. The comments on Ned’s post are well worth reading; they’ve provided me with a new blog to subscribe to, Jeff Darcy’s Canned Platypus which seems to have lots of the kind of high quality techie stuff that I like.

My view on multi-threading is probably pretty obvious given the way my socket server framework is designed…

I’m not scared of using threads when they’re appropriate, and, as Ned says, it is difficult and you do have to abide by certain rules. It’s not something I’d want everybody doing because, quite frankly, lots of developers don’t pay enough attention to what they’re doing…

Developing high performance servers on Windows pretty much requires multi-threading, ideally in the form of IO Completion Ports and a thread pool. The interesting thing about an IO Completion Port based design is that the focus shifts from working with multiple threads, to working with multiple event-driven state machines… Some people find that a difficult shift to make. It seems, from the C10K document, that this approach has not yet really taken off over in Linux-Land. The event-driven state machine approach is actually quite similar to what you need to do if you use just one thread and non-blocking IO. It’s also what some of the people who don’t like threads think you should be using as an alternative. For me IO Completion Ports let you exploit the processors that you have and do so in a way that works well and scales well. You do have to spend a little bit of time learning how to do it properly though…