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