apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: apr/include apr_sms_trivial.h
Date Sun, 01 Jul 2001 17:07:24 GMT
On Sun, Jul 01, 2001 at 02:56:13PM +0200, Sander Striker wrote:
> >   This is based off of his submission to dev@apr from a few weeks ago - he
> >   might have a newer version locally that he hasn't posted.
> 
> There were only minor diffs between my local version and the one
> posted earlier. Just committed those.

Cool.

> There was one fix, but Justin already caught that. Thx :)

Hehe.  =)  Yeah, I added that return value.

> We probably need to take a look at the list handling and see if
> we can speed this up a bit.

Yeah, I tried trying to walk through the sentinel code last night and my
brain just wasn't parsing the code.  It does need to be looked at with a
fine-toothed comb.  I might get around to it later this afternoon.  It
almost calls for pencil and paper to sketch out what the code is doing.

> Also, the values need tweaking (MAX_FREE, MIN_ALLOC, MIN_FREE). But
> I think we should wait with that until we have a good testing
> environment.

I wonder if you even need the MAX_FREE, MIN_ALLOC, and MIN_FREE stuff.
Shouldn't we just leave those to the parent SMS?  That makes more sense
to me.  I'm not really sold on the trivial SMS doing this sort of thing.
(This sort of thing is WHY we have SMS in the first place, IMHO.)

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.  =)  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 
going to see a benefit from SMS long-term.  -- justin


Mime
View raw message