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/threadproc/unix thread.c
Date Wed, 06 Jun 2001 22:47:53 GMT
> On Thu, 7 Jun 2001, Sander Striker wrote:
> > Argh!!! [getting abit frustrated now, because there seems to be no
> > way of moving forward and thus proving the system]
> I think we're at least starting to face the issues head-on.  We're making
> progress, believe it or not.  =-)

Yes we are!

> > > See, that's where my overall view of "where we hope to get to"
> > > <shrug>  In my mind, APR depends on pools.  Period.  It would require
> > > major overhaul for most APR operations to be safe WITHOUT pools (ie,
> > > of apr_sms_free operations would have to be added, which is exactly
> > > the pools are meant to avoid).
> >
> > This is simply not true. Where you pass in pools at the moment you'll
> > in a _tracking_ sms later. This guarantees that stuff is free'd later
> Hmm...
> > > and you get to select where the pool gets its memory from under the
> > > (does it come off the heap, or out of shared memory, or what?  The sms
> > > that the pool's based on decides.)
> >
> > What you are basically saying is that you want tracking to be
> > mandatory instead of optional. Why another level of indirection? sms
> > is flexible enough to do what pools can do [apart from an abort
> > function it has almost all the same features. Oh and locking
> > ofcourse...]
> Okay, so you've convinced me that it's possible to do.  But it's not going
> to happen throughout APR in time for Apache 2.0, I think (I doubt anyone
> here would disagree).  So what are the intermediate measures?  I'll step
> back now and let you all sort that out.

This is the crux of the issue methinks.  We don't yet have a module that
would allow us to even get close to replacing pools.  We need a lot of
things from it and Sander and I have had some good early discussions about
how it could work.  Basically we want to have a fast, stable tracking
allocator that has a smaller memory footprint than pools.  Is it possible?
I don't honestly know but we're going to give it a good try.  Why haven't we
opened up our discussions?  Because we haven't even got any code and are
still bashing around the early design which is probably better done
privately.  Once we have something we like we'll post.

When looking at the code that's there please bear this in mind.  The current
apr_sms_tracking module does some of the things that pools do, but it's by
no means a replacement.

The whole structure of the sms code means that we can have a lot of
different methods of allocating/tracking it's memory.  the main limit is our
imagination and coding :)  Well mainly coding in my case :)

What do we do here and now?  Exactly what we've been doing.  With the pool
in the sms we have access to all of APR (so it's a better solution than my
original - thanks Greg) which means we can move forward and start developing
some of the things we want and actually code them.  The process has revealed
some problems in our assumptions and in some of our code - witness the
changes in locking that I made as a result of trying to get locks into sms -
and so it's a valuable process to go through.

Things on the agenda...

- a "pool replacement" sms module
- shared memory support
- debugging modules (one just to debug and one that dumps memory to files)

To be honest there's enough there to keep us occupied for quite a while to
come.  There's also the possibility that we'll arrange some face to face get
togethers to work through some of this, but as Sander, Luke and myself are
in europe they'll be this side of the water, probably in the UK.

> > For people considering -1, please reconsider and cut us some slack so
> > we can at least try and prove our case. If we don't prove anything issue
> > a -1 later and we'll cut the code out [does this sound fair David?]
> Okay by me.

OK by me as well, as I think I've shown :)


View raw message