[Catalyst] Memory leak under FastCGI?

[Matt S Trout]

On Fri, Apr 11, 2008 at 11:20:53AM -0400, Matt Pitts wrote:
> > The accept() happens in the child in normal situations though, so the
> > parent can't know how many requests a given child has handled without
> > additional complication.
> 
> Yeap. My version of the "additional complication" is a lite IPC
> messaging system using DBM::Deep. I override post_dispatch in the
> children to send a message to the queue that says "I just finished
> handling a request" and then the manager iterates the message queue
> during each daemon loop and keeps track of each child's request count.

Yuck.

Seems much simpler to me to do something like:

Child1 hits request count, sends SIGUSR1 to proc manager, starts exiting

Manager sends SIGUSR1 to all other children

(child may take a while to clean up, exit happens somewhen)

Other children go into "must not die" mode

Manager spawns new child once it gets SIGCHLD

New child sends SIGUSR2 to proc manager once it's starting its accept()
loop

Proc manager sends SIGUSR2 to all children to indicate they're allowed to
die now if they want to

Seems a lot more unixy to me, and likely much less overhead as well.
 
> This obviously introduces some overhead to the post_dispatch call, but
> I'm thinking that since MyApp->handle_request has already been called
> that all data has been sent to the client (buffering?), the only thing
> that might not have happened yet is the closing of the FastCGI
> connection with the socket.
> 
> Am I wrong? Can anyone elaborate on the effects of doing this in
> post_dispatch?
>  
> > Basically, you -can't- manage it in a single place. A "don't die for a
> > bit,
> > somebody else just did" mechanism would be good as a co-ordination
> > between
> > manager and children and IMO should be implemented separately.
> 
> My plan is to build it as a subclass of FCGI::Engine::ProcManager so
> folks can use it at their own discretion.
> 
> v/r
> 
> -matt
> 
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/