apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Thu, 07 Jun 2001 14:00:38 GMT
On Wed, Jun 06, 2001 at 03:51:55PM -0700, Ian Holsman wrote:
> 
> 
> > -----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.

i think that putting
#define apr_pool_t apr_sms_t and
#define apr_pool_create apr_sms_pool_create
...
etc.

stands a much better chance of a) success b) being accepted

because a) the developers can write tests that prove that the
existing code that uses pools - UNMODIFIED - is unaffected
by using apr_sms_pool_create or apr_pool_create whatever-you-like
_and_ you can write a test suite that does random / specific
memory tests using both systems and comparing the results

b) if you don't _like_ the implementation of apr_sms_pool_create
and friends, well, uhh.. you remove the #defines in apr_compat.h
and you're done: you're back to where you started, no harm done.

luke

Mime
View raw message