Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 03 Jul 2004 10:43:30 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Paul Querna <chip@force-elite.com>,
   Craig Rodrigues <rodrigc@crodrigues.org>
cc: dev@apr.apache.org
Subject: Re: FreeBSD APR patch for threads
Message-ID: <C926C6AC7958138F60269596@[10.0.1.36]>
In-Reply-To: <1088850255.6502.59.camel@localhost>
References: <20040702194354.GA60584@crodrigues.org>
 <1088850255.6502.59.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Saturday, July 3, 2004 3:24 AM -0700 Paul Querna <chip@force-elite.com> 
wrote:

> I do not believe there is any reason to disable thread support in APR
> itself.  Even on 4.x where the native threading is horrible, and the
> Worker MPM is broken.

Yes, there is.  Lots of weird and subtle things break when threading is 
enabled on FreeBSD.  Besides the well-documented worker MPM problem, 
Subversion fails to display certain important prompts when threading is 
enabled - which make Subversion inoperable with threads enabled.  (Disabling 
threads on FreeBSD makes the prompts appear.)

We've hit this with minotaur.apache.org which is FreeBSD 4.10 - it made it 
impossible for us to commit on our own SVN server!  Since libxml2 at one point 
used threads which was used by neon which is used by Subversion, Subversion 
implicitly enabled threads and circumvented APR's disabling of threads. 
(FWIW, libxml2 has since been configured to not use threads in FreeBSD ports.)

So, this just isn't httpd or a flaw in the worker MPM model - the bugs in the 
threading library have been seen even without programs explicitly using 
threads.  The best we can tell for the Subversion bug is that the scheduler 
gets confused and eats an important fd that should be displaying a prompt.

If it works for you, good - but *I* absolutely don't want to track down bugs 
in the FreeBSD threading code - I've seen enough not to trust that code at 
*all*.  FreeBSD 4.x's crappy gdb doesn't help track down problems either - at 
least 5.x sort of supports current gdb's - but that work is continuing in 
-CURRENT.  Besides not supporting threads properly, gdb's support for FreeBSD 
4.x shared libraries is utter junk.  -- justin