Cyrus process model...

[Rob Mueller]

>   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