On 21 Feb 2001, Jeff Trawick wrote:
> Charles Randall <[EMAIL PROTECTED]> writes:
>
> > From: Jeff Trawick [mailto:[EMAIL PROTECTED]]
> > >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).
perchild is horribly broken right now. I have a mostly working patch on
my computer right now. Expect the commit soon-ish.
> > >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.
Exactly.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
