apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: cvs commit: apr/threadproc/unix thread.c
Date Wed, 06 Jun 2001 22:51:55 GMT


> -----Original Message-----
> From: Sander Striker [mailto:striker@samba-tng.org]
> Sent: Wednesday, June 06, 2001 3:13 PM
> To: Cliff Woolley; David Reid
> Cc: APR Development List
> Subject: RE: cvs commit: apr/threadproc/unix thread.c
> 
> 
> > 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]

maybe you could take a bit at a time

for example.. modify the pool code so that it has a 'sms' memory pointer
in the structure, on init/destroy you also clean it up ..

then you could takle parts of the apr, for example strings
replacing the 'standard' pool memory functions it uses with sms
memory calls in their place, as long as the 'standard' and SMS memory
have the same lifetime.

then maybe buckets.. 

how does that sound?
> 
> > > 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
> 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...]
> 
> > 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()
> calls.
> 
> > 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?]
> 
> Sander
> 
> 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...
> 
> 

Mime
View raw message