apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] apr_lock.h update to remove/fix CROSS_PROCESS vs LOCKALL
Date Tue, 03 Jul 2001 19:45:15 GMT
On Tue, Jul 03, 2001 at 03:02:47PM -0400, Jeff Trawick wrote:
> that makes sense to me too for my own purposes, but
> 1) before long I suspect some folks will want/need a single shared
>    library version of APR which works with multiple APR apps
>    and it won't just be "want" because they think it will be nicer to
>    have one build of APR... it will be "need" because different
>    dynamically-loaded code will have to use the same copy of APR*
>    (*maybe gstein could chime in here... some months back there was a
>    discussion of why single shared library of APR was so important)

Maybe we could take the libc approach and build libapr and libapr_r.
Not sure how I like that though (my first thought - yuck!).  That 
sort of rubs me the wrong way.  

Compiling APR with threads and using it with something that isn't
threaded won't break anything - in this case, you just may acquire an 
extra potentially unnecessary lock here and there.  So, don't scream
about performance.  It should all work though.  But, when we do *have*
threads, we need to make sure the locking is done right.  That 
currently isn't the case.  

> 2) even if, back to the Apache example, we use the prefork MPM, we may
>    have a module which uses threads; I've been told there are threaded
>    modules for Apache 1.3...; presumably we'd want such modules to
>    work with APR with Apache 2.0

Then, they pay the penalty that all of the stock Apache 2.0 calls to
APR now have to be locked when they don't necessarily have to be.  
It's a tradeoff.  

I'm not seeing any functionality loss here.  Maybe I'm wrong.
-- justin

View raw message