apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: apr STATUS
Date Thu, 28 Jun 2001 05:14:30 GMT
jerenkrantz    01/06/27 22:14:30

  Modified:    .        STATUS
  "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 @@
  -Last modified at [$Date: 2001/06/28 04:03:19 $]
  +Last modified at [$Date: 2001/06/28 05:14:28 $]
  @@ -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:

View raw message