[...]
> > > 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
|