Another question about pool strategies

FROM : Matt Mashyna
DATE : Fri Feb 15 22:13:27 2008

I've been playing with a server app that listens for connections on a 
port by setting up an NSFileHandle with a 
NSFileHandleConnectionAcceptedNotification notification. It's all nice 
and tidy with Cocoa. What I run into is a growing pool footprint. 
MallocDebug tells me that none of my objects are leaking but the 
footprint grows because I haven't found the right way to manage the 
pool.

I run into trouble, I think, because the notification that a 
connection has arrived causes some new objects to be allocated, used 
and then released but this happens asynchronously. Some objects hang 
around for follow up connections and are released later. These 
objects, I think, never get drained.

For a server process this is not acceptable because it slowly uses up 
app the system memory.

I'm looking for a strategy that will allow me to set up a pool I can 
periodically drain in an asynchronously driven system. I tried to set 
up pool in my controller object's init method, that starts listening, 
and drain it when the connection closes but that doesn't seem to work.

I'd like some advice to reorganize my project to keep the pool for 
growing out of control.