On Fri, Mar 02, 2001 at 09:03:59PM +1100, Luke Kenneth Casson Leighton wrote: >... > in xmlvl, i investigated splitting out the pool code into stackable pools. > sander and i came up with sma_mem_sys as a result. > > imagine that you want to do secure memory stacking, using the gpg > memory-locking method, but you don't want to have to rewrite entire > sections of apr and apache to do it. > > passing in a sma_mem_sys (which is an array of parent-pool functions) > which does gpg-style memory-page-locking into apr_pool_creeate(), you can > do this. > > the "default" parent-pool sma_mem_sys of course should be one that wraps > malloc and free. > > you can then define sub-pools to use an apache-pool sma_mem_sys, and in > fact, the only difference then between a sub-pool and the global pool is > that the sub-pool uses an apr-sma_mem_sys instance whilst the global pool > uses a malloc/free-sma_mem_sys. > > i'm going over to sander's at the w/e, we'll see if we can thrash it out.
Please let us know your result. We've talked about types of pools before. One that keeps the current semantics, one that maps straight to malloc/free, and one that handled shared memory. I didn't know about a GPG memory type :-) Sounds way cool, and I definitely bet that we could use that within Apache. We have had some problems with the pool types, however. Consider that you pass a function a malloc-based pool. Who calls the free? The function doesn't know whether it is a standard pool, or a malloc pool. And inserting a bunch of apr_pool_free(ptr) calls (which are noops for some pools) defeats the purpose of using pools to avoid carefully tracking free(). For shared memory, I think we were having some issues with grabbing the right amounts of shared memory, then doing the suballocations. I think this can be solved, though. I do like the idea of pool types, and I know others do, too. At least from me, there is a big +1 on integrating GPG pools into APR. Cheers, -g -- Greg Stein, http://www.lyra.org/
