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: SMS stuff
Date Fri, 08 Jun 2001 12:53:28 GMT
> 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

Mime
View raw message