Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: trawick@bellsouth.net
To: new-httpd@apache.org
Subject: Re: perchild mpm on FreeBSD 4.2
References: 
 <5FE9B713CCCDD311A03400508B8B3013054E40D5@bdr-xcln.is.matchlogic.com>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 21 Feb 2001 16:17:46 -0500
In-Reply-To: 
 <5FE9B713CCCDD311A03400508B8B3013054E40D5@bdr-xcln.is.matchlogic.com>
Message-ID: <m34rxnwxad.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 58
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Charles Randall <crandall@matchlogic.com> writes:

> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> >try the patch at the bottom...
> 
> That works with the source with a cvs datespec of "2/19/2001 10:00
> MST".

I'll commit, once I verify that it still works (lots of stuff changing
lately).

> With a fresh cvs update, there are two new problems.
> 
> First, it looks like stdint.h (?) is now included in APR's mktemp.c. There's
> no stdint.h on FreeBSD.

solved...  I committed something two hours ago (or so) to resolve
that.  The guts of mktemp.c should be hidden on FreeBSD now... let me
know if this isn't the case on your system.

> >Now you get to the almost indescribable problems we've had running a
> >threaded MPM, or even a non-threaded MPM which links with libc_r and
> >adds a thread lock here and there within APR, on various levels of
> >reeBSD.
> 
> You see this with the prefork mpm too? Is there a reproducible test case or
> is it seemingly random?
> 
> Could it be related to this output from configure?
> 
> --
> Applying APR hints file rules for i386-unknown-freebsd4.1
>   Adding "-lcrypt" to LIBS
>   Setting enable_threads to "no"
>   Adding "-D_REENTRANT -D_THREAD_SAFE" to THREAD_CPPFLAGS
> --
> 
> Why is enable_threads "no"?

because in our experience, pthreads and libc_r on FreeBSD are
problematic.  Maybe we are tickling libc_r in a way that it doesn't
handle.

On some level of 4.2 , the main process in prefork
loops.  On 3.4, I have seen select() refuse to pop even with a timeout
specified, I have seen open() give me a file which fcntl(,F_GETFL,)
says is write-only but which was just opened with O_RDONLY.
Pretending that thread support isn't there has solved all of these
problems.

If somebody wants to use threads, *I think* they just have to add
--enable-threads to the configure cmd-line.  We won't enable them by
default but we won't prevent someone from trying.

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...