On Thu, Jul 12, 2001 at 02:50:17AM -0700, Brian Pane wrote: > >in other words, would it be better to have an extra parameter to > >the malloc to indicate what the sms should do? advice to the > >sms as to the _type_ of alllocation being performed? > > > Here's a possible taxonomy of allocation types: > > Type 1: Allocations that will not be returned to the SMS (and will > get freed only when the SMS itself is destroyed) [or reset to as-if-it-had-just-been-created]
> Type 2: Allocations that will be returned to the SMS during its > lifetime > [... description of scenarios cut] > Using this model, an SMS itself could figure out the type of > each allocation request based on the number of bytes requested: > small requests would get allocated out of the pool as in > apr_sms_trivial, and large requests would get delegated to > a root SMS that called malloc. (I guess an SMS that did this > would be a hybrid tracking/trivial SMS?) ooo! *goggle-eyed*. y'know what i like about SMS? that it allows people to _have_ these discussions. [the ultimate decision is, of course, well, we found out that pools are The Best, and rip the whole lot :)] ... what approach is taken by The Best memory allocators. and do we wish to 'reinvent their wheels'? do we have any _choice_ but to reinvent, or at least follow, the inventions? i've heard suggestions of creating one sms per thread, one per processor, etc. and these are because existing memory libraries already do this. ... food for thought. luke
