Sean Chittenden <[EMAIL PROTECTED]> said: >> So, we should crib a memory pool API from someplace (IIRC, Timo >> Sirainen has a good one in Dovecot that is MIT licensed) or write >> our own in Glib style and send it upstream (probably a bigger >> project than it needs to be). > > Why? To avoid the constant free(3)'ing?
Yes, exactly. Keeping track of each malloc to properly match it with a free is a huge pain in the butt and a constant source of trouble. And, as good C programmers, we're supposed to have a distaste for garbage collection ;-) >> Memory pools are big chunks of malloc() memory that we request from the >> system and then use for ourselves as needed in smaller pieces. In >> Apache's >> APR implementation (which is really, really bloated) you can also nest >> pools. Rather than a malloc/free pair for every string, you just make a >> pool, "malloc" from the pool recklessly ;-) and then when you're all >> done, >> free the entire pool back to the system. > > I'm in favor of stability, then optimizing later. :) In all > seriousness, this is what FreeBSD's malloc(3) call does (and is why > it's really quick). The system's malloc only closes the "application pool" when the application closes. We're writing a daemon, so this functionality is basically useless. Hence the need to write something similar that works within the application. For example, on a per-connection basis, where the memory used by a client is freed when they close the connection. (There'd still a need to be vigilant so that we don't run up too much memory on a connection that's open for a long time, though.) And, most saliently, where the memory used to service a command is freed once the command has been responded to. Aaron --
