Another question about pool strategies

  • 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.