On Wed, Jun 06, 2001 at 03:51:55PM -0700, Ian Holsman wrote: > > > > -----Original Message----- > > From: Sander Striker [mailto:[EMAIL PROTECTED] > > 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
