apr-dev mailing list archives

On Thu, Jun 07, 2001 at 03:35:14PM +0200, Luke Kenneth Casson Leighton wrote:
> > > Point out that requirement, and you can change a lot of minds here. But
> > > until then, I think you'll continue to see confused/concerned people, not
> > > understanding why you are suggesting we toss all of the memory management
> > in
> > > APR in favor of SMS.
>
> uh, sorry to have to point this out like this, but your understanding
> of the original plan for SMS usage is plain wrong.
>
> i have no idea what makes you think that anyone is suggesting that
> all mman in APR is 'tossed' in favour of sms, and if anyone
> else recommends it i will bitch at them persistently until they give
> a decent justification, or give up. :)
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.
>...
> please, like david did, if you don't like or don't understand
> the explanations, please read the code. it's really short,
> it's really simple - and it's short and simple _because_ we
> [collectively - all of us] have enough experience to realise
> that anything else will cause us to have nightmares until the
> code's ripped out and burnt. ritually.
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, then I question why we have a pool underneath an SMS.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/