Your response is exactly why I want to go with threading: because I can solve all my hard problems via shared memory vars, easily reconnecting a request to it's output stream. But I have to face some unhappy facts: I don't know enough about threading to know what's necessary to keep the thread memory consumption from ballooning out of control. I also don't know how to handle corner cases that I've yet to identify with the creation of a highly-available multi-threaded network service. And finally I don't yet know gracefully kill off threads that get "stuck" without resorting to a SIGKILL (which isn't exactly a showstopper, but the other issues are).

The multi-threaded IRC chat bot code that was shared earlier in this discussion is too bare-boned to inspire confidence that extending it could handle the problems I've outlined above. If I venture down this path, I'd need a map and a guide. And frankly the latter and more essential of the two is hard to come by in *nix land where forking is king and threading has a bad reputation for, from what I can tell, all stupid reasons.