apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: Catch 22
Date Wed, 30 May 2001 12:49:14 GMT
[...]
> > > what you think?
> > 
> > Well, the best way would be turning pools into sms. Then #define
> 
> that's what i kinda assumed would be advocated.  

But that is not the case. Pools are to be untouched until further
notice.
 
> > all the pool functions to actually be sms functions.
> 
> means that things like guaranteed destruction-order also
> have to be in there, etc. [cf: the apr_pool_join discussion]
> 
> if _that_ happens, sms pretty much just turns _into_ pools,
> only stackable.  which i had hoped wouldn't happen.
> 
> i'd like the sms API and principles to be kept simple:
> simple enough so that it's easy to implement to it and
> also easy to use and understand.
> 
> however, if apr_sms_pool can be implemented such that it
> relies on functionality in sms that is currently embedded
> into apr_pool [e.g. the destroy stuff], i'd be happy.

That is pretty much the case.
 
[...]
> > I want to avoid more layers of indirection, because in the final
> > product they are simply not needed.
> > 
> 
> ack.  more layers, less speed.

Yep.
 
> luke

Sander


Mime
View raw message