But we are still trying to link in pthreads, as witnessed by me getting
"pthread_sigmask" not found link errors on Darwin when building using
the prefork mpm. Or else it's just autoconf crud.
Chuck
On Thursday, April 26, 2001, at 03:18 PM, William A. Rowe, Jr. wrote:
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Thursday, April 26, 2001 1:57 PM
>
>
>>>>> This stuff came up while Justin and Aaron were performance testing
>>>>> mod_mbox -- right now you can double the requests per second simply
>>>>> by recompiling with --disable-threads.
>>>
>>> Wow, which MPM are you using? That is actually quite a suprise to me
>>> as Apache 2.0 performance is
>>> close to that of Apache 1.3 (on AIX at least) which does not use
>>> pool locking or buffer locking for
>>> file i/o.
>>
>> We are currently using prefork because pthread is completely useless at
>> this point. Hopefully, the signals stuff gets fixed soon... Actually,
>> on FreeBSD, threaded MPMs are disabled, but no one tells APR, so it
>> defines APR_HAS_THREADS - we need to fix that. I may submit a patch
>> for
>> that - just add --disable-threads to APRs configure for these
>> platforms?
>
> Hmmm... notice that APR_HAS_THREADS is irrelevant to the MPM
> selected... you
> _can_ using threading support in APR with a prefork MPM, and there may
> be
> modules that need just that configuration someday soon (say, child
> threads
> in a mod_proxy or servlet environment).
>
> So you can't indiscriminantly disable APR threads 'just because', there
> is
> going to need to be a bit more logic. Contrawise, just because the user
> enables APR threads does _not_ mean they are choosing pthreads ;-)
>
> Bill
>
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
