Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Tue, 10 Sep 2002 09:39:01 -0700 (PDT)
From: Rasmus Lerdorf <rasmus@apache.org>
To: Cyrille Artho <cartho@email.arc.nasa.gov>
cc: dev@httpd.apache.org
Subject: Re: Thread safety issues
In-Reply-To: <3D7E16B6.7060805@email.arc.nasa.gov>
Message-ID: <Pine.LNX.4.44.0209100938510.13509-100000@www.lerdorf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Contributions are more than welcome.

On Tue, 10 Sep 2002, Cyrille Artho wrote:

> Hi,
> as someone who works on multi-threaded problems, but not Apache, I ran
> into your page at
> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
>
> I strongly suggest to revise it, because it lacks depth. First of all,
> you probably should start explaining the basic problem in case a
> developer has never used threads: what is a race condition (and what is
> a deadlock), why is it hard to test (because it is scheduling-dependent,
> the scheduling cannot be controlled).
>
> What can be done about it (manual analysis, VisualThreads under Alpha).
> Basically the programmer has to ensure that each access to shared data
> is protected by at least one common lock (the word "common" is important).
>
> When to use apr_atomic_* and apr_thread_mutex_*. How to use them.
>
> Perhaps make a small shell script that parses the ldd output and
> compares each line to a "database" of libraries in it, printing
> problematic libraries.
>
> Maybe you can cover some of these issues by linking to other pages. It
> is important that they are well documented, otherwise people will never
> dare using 2.0 or writing modules for it.
>
> I personally hope 2.0 will be adapted fast, but I know such things take
> time. Good luck, and keep up the good work!
> --
> Regards,
> Cyrille Artho
>