apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: cvs commit: apr/threadproc/unix thread.c
Date Wed, 06 Jun 2001 22:13:16 GMT
> On Wed, 6 Jun 2001, David Reid wrote:
> > There is no pleasing some people is there??
> Nope.  =-)

Argh!!! [getting abit frustrated now, because there seems to be no
way of moving forward and thus proving the system]

> > At present pools are a specific implementation of memory management.  In
> > time we hope to get sms to a point where we can replace pools
> > with an sms
> > module that is better.  When we get there, it won't matter that we have
> > pools in the sms code as when we replace the pools we'll have
> > to go through
> > and change all the apr code.
> >
> > apr_pstrdup(apr_pool_t *pool, char *str)
> > we'll end up with
> > apr_pstrdup(apr_sms_t *mem_sys, char *str)
> See, that's where my overall view of "where we hope to get to" differs.
> <shrug>  In my mind, APR depends on pools.  Period.  It would require a
> major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> of apr_sms_free operations would have to be added, which is exactly what
> the pools are meant to avoid).

This is simply not true. Where you pass in pools at the moment you'll pass
in a _tracking_ sms later. This guarantees that stuff is free'd later on.

> So in my mind, you implement pools ON TOP OF sms.

Well, this is not for me to decide, but my personal opinion: yuck!

> That gives you the best of both worlds: you get the convenience of the
> pool API,

Including tracking which you don't need if you have a tracking parent sms
and are only freeing when the parent is freed (ie, a sms associated with
a connection or a request). Also the pool API is a lot less flexible.

> and you get to select where the pool gets its memory from under the covers
> (does it come off the heap, or out of shared memory, or what?  The sms
> 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
to do what pools can do [apart from an abort function it has almost all the
same features. Oh and locking ofcourse...]

> So you can't do
> newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
> because then you have to be sure to
> apr_sms_free(str)
> because you don't know for sure whether the mem_sys will do it for you or
> not.

Which should be the choice of the user, not for the apr library IMHO.
In other words, it should be up to the user when to free, either through
an apr_sms_destroy() on a tracking sms or through explicit apr_sms_free()

> So that means you have to keep
> newstr = apr_pstrdup(apr_pool_t *pool, char *str)
> and change the apr_pool_t struct to include an sms, and to get its memory
> using apr_sms_malloc instead of just plain old malloc.
> That's my take on things, anyway.

My fl 0.02 :-)

> > As for locking, well the logical level for locking to be
> > implemented is in
> > the sms module.  Look at the standard module. malloc should be
> > thread safe
> > so no locking should be required, hence we don't have any.  In
> > a tracking system we can't guarantee that so we lock.

To clear this up: this is because we have internal structures in the
tracking sms that are modified when allocing/freeing etc.

> I don't really have a problem with the locking end of things, per se...
> there will probably be some SMS's that need to lock, so we might as well
> give them a convenient means to do so.  I think.  I haven't really looked
> into this, though.
> > So, do I still hear -1's for the pool in sms approach?
> I'm not going to say -1... just -0.  <shrug>

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?]


PS. No, I'm not worked up at the moment and yes my comments are a bit,
    what's the word, rigid, but that's just because I'm very tired...

View raw message