apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: apr STATUS
Date Thu, 28 Jun 2001 05:17:40 GMT

Not to be contrary, but this can be easily resolved, by passing in a
simple flag when creating a pool.  That flag tells us whether or not we
should lock when using the pool.

Ryan

On 28 Jun 2001 jerenkrantz@apache.org wrote:

> jerenkrantz    01/06/27 22:14:30
>
>   Modified:    .        STATUS
>   Log:
>   "I'm mad as hell and I'm not going to take it anymore."
>
>   The threading and pool stuff just don't mix.  If we ever plan on
>   getting Apache 2.0 to work WELL with threading, this needs to be
>   addressed.  The most likely way to address this is via SMS.  I
>   need to play more with SMS to determine how close this is to being
>   ready for prime-time.  I may need to clean up SMS first.
>
>   Expect this to be my focus once I get freed up at my day job.
>   (Hopefully, end of this week...)
>
>   Revision  Changes    Path
>   1.47      +18 -1     apr/STATUS
>
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/apr/STATUS,v
>   retrieving revision 1.46
>   retrieving revision 1.47
>   diff -u -r1.46 -r1.47
>   --- STATUS	2001/06/28 04:03:19	1.46
>   +++ STATUS	2001/06/28 05:14:28	1.47
>   @@ -1,5 +1,5 @@
>    APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:			-*-text-*-
>   -Last modified at [$Date: 2001/06/28 04:03:19 $]
>   +Last modified at [$Date: 2001/06/28 05:14:28 $]
>
>    Release:
>
>   @@ -146,6 +146,23 @@
>          - add to the default build as currently it's omitted.  Also need to
>            add testmem to the test build at that point.
>          - add more detailed tests to testmem.c
>   +
>   +    * In line with the new SMS code is the fact that threading and pools
>   +      just are not working together well.  This is due to the fact that
>   +      the pool code has one global mutex (alloc_mutex) and one freelist
>   +      (block_freelist) for all pools to share.  This means that only
>   +      one worker can be allocating memory at any given time.  This is
>   +      probably the reason why Apache 2.0 is faster with prefork MPM
>   +      (thread-disabled APR) than threaded MPM.  The solution to this
>   +      is most likely to incorporate a rework of the pools to use the new
>   +      SMS code and allow certain pools (i.e. request pools in httpd-2.0)
>   +      to have an option for no locking (as they can't have contention
>   +      by definition).  This would mean that the mutex and freelist
>   +      must be moved inside of apr_pool_t.  Therefore, this is the
>   +      jumping-off point into SMS.  Short-term, it is *possible* that
>   +      ALLOC_USE_MALLOC would be faster than the current pool code for
>   +      a threaded APR (but, I'm not sure).
>   +        Status: Justin volunteers
>
>    Documentation that needs writing:
>
>
>
>
>
>


_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message