> > > > note absurdity of apr_dbm_freedatum in a pool-managed implementation > > > > > > The returned data is not always located in a pool. Specifically, GDBM's > > > return data is malloc'd. SDBM's return data is from a shared block of > > > memory. [hmm. sdbm's behavior should be clarified in the docs] > > > > Of course not, but it should be. > > No way. No no no. You could pull several hundred Kbytes of data from a GDBM > record. We cannot and should not copy that into a pool. Take a page from > Ryan's book and attach a cleanup to the pool to free() the block at pool > cleanup time. > > Hell, we use the cleanup function (rather than pool allocation) all over the > place in the bucket code. > > There is no reason to take the hit of a memory copy when a simple > registration is sufficient.
Actually, that's not true. I have added SDBM support to a couple modules recently, and while everything just works on Linux and FrreBSD, it blows up on all Solaris machines. Basically, on solaris just referencing the data in a datum returned by sdbm_fetch will cause a SIGBUS. This is easily reproducable, and is solved by memcpy'ing the data before trying to reference it. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
