> Here is why I thought that: > > David Reid wrote: > > When we're done we'll have > > > > locks -> apr_sms_t > > sms -> locks -> apr_sms_t > > > > So personally I don't see the problem and thus I made the change! I guess > > maybe it's because people keep saying that we're going to change the pools > > to use sms. Why? To get the maximum flexibility we'll need to use sms > > throughout so while we may have > > > > apr_pstrdup(apr_pool_t *pool, char *str) > > > > we'll end up with > > > > apr_pstrdup(apr_sms_t *mem_sys, char *str) > > > So no wonder I'm a bit concerned. ack.
... okay. doing a half-way-house isn't going to satisfy you, me, or anybody. david clarified in a later post, on the above. sander's written up a roadmap that outlines what me, sander and david agree on, and it takes into consideration everyone's concerns: that's my take on it, anyway. > I haven't complained about the code one bit. Yes, it is simple, but reading > it isn't change what I'm talking about... I have an issue with what we're > going to *do* with it. And given that I believe SMS with providing storage > for a pool, ack. > then I question why we have a pool underneath an SMS. me, too, don't worry! :) okay, there are two approaches to do "SMS with providing storage for a pool" 1) implement apr_pool.c to call functions in apr_sms 2) provide exactly the same functionality and then #define. if 1) just becomes a thin wrapper, then it's pointless function overhead and you might as well do 2) _anyway_! luke
