> It is always a big pain to update code that was never written to be > threaded, to be thread-safe. Apache2 has a problems with just about every > third party module supported under Apache 1.3. I imagine that Cyrus would > have all sorts of thread issues. There is no magic solution for that.
I'm not convinced that it's necessary to make it thread safe. In many situations I think threads are a step backwards. While it always feels a bit odd to think of it as a positive, the multiple process model introduces an inherent stability, even for non-optimal (buggy) code that can crash a process. In that case, only one connection/instance is lost, and no-one else is affected. In multithreaded code, one bad crashed thread *can* take out the entire process and all connections. Of course, if your code has to share a lot of information between each 'instance', then threads are very useful. In the case of cyrus, I think you can quite happily stick with the multi-process model, I wasn't advocating moving to a threaded model. The discussion started due to an issue with killing child processes. Apparently there are currently race conditions in 'master' that means that a killed child may not be correctly recognised by the 'master' process as a dead child. I commented that I thought a master/forked child idiom had been used in unix for 30 years, and shouldn't there be cookbook solutions for most of these issues? Which started me looking for libraries that might have already done this... > Besides, if anyone really wants to take Cyrus to the next generation, > create a new NG branch in CVS (on your own CVS server if necessary), and > start "refactoring" away. (Of course, "refactoring" has to be the most > overused term in software development at the moment, and is touted as a > solution for everything from bad design, to poor management). The thing is, in my experience, refactoring actually works, regardless of it's buzz word of the week or not. Better yet, *continuous* refactoring seems to work the best! Hmmm, not that I find that easy to define. I guess it's being aware as you work on a project, which parts are clearly beginning to feel 'wrong' (hmmm, more subjective thoughts...), and devoting some time to actually fixing up those problem areas. This is generally a lot easier if you're good at creating interfaces and sticking to them. Of course, being forced to work around an interface is one of the clear signs of something being 'wrong'. Rob