Cyrus process model...

[David Lang]

I will also add that on current *nix systems the advantages of threads
over processes is a lot less then it used to be. In my case we are running
apache2 on AIX and found no noticable difference between the two (so we
are useing processes for the stability reasons you note below)

David Lang

 On Thu, 27 Feb 2003, Rob Mueller wrote:

> >   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
>