apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/include apr_sms_trivial.h
Date Mon, 02 Jul 2001 06:35:57 GMT
> > I think with the testmem and Ian's testpool, I think we are close to 
> > having a decent testing environment that is outside of the "real" 
> > world.  The only thing I'm waiting on now is David's implementation of
> > apr_pool_t as a SMS.  =)  

OK, OK, it's on it's way :)  Patience is a virtue!

> We need some decent debugging :)

Yes, we do!  First steps on the way real soon now!

> > I was shocked that trivial was 102-103% of 
> > the pool code (based on testmem results).  This is *without* 
> > multi-threaded/unlocked allocation, which is where I believe that we're
> There is a lock in the sms framework that is enabled by default. It is
> acquired when apr_sms_reset is called. This lock has to be dynamically
> created as the rest of the locks. I have a decent scheme in mind which
> I will post Real Soon Now(tm).
> If you disable the lock creation in apr_sms_create() [or, wait, we
> moved it to apr_sms_post_init()] you should get better results. Also,
> if you increase the MAX_FREE to a lot bigger you come closer to pools,
> which doesn't free memory at all. With sms, you give it back to the
> parent, which may hold on to it itself, or may give it back to the
> system (which means that when a box has low load, the memory use
> will go down).
> > going to see a benefit from SMS long-term.  -- justin
> Yes. Btw, I'm doing some last mods on an sms which I called threads_sms.
> It is to be the parent sms of the smss that are in different threads.
> It is based on trivial and has some nice properties when it comes to
> locking. I'm hoping this will be a speed improvement in a threaded
> environment. I will have to commit some groundwork for use later on
> for that though.



View raw message