[Catalyst] Some more FastCGI improvements

[Sam Vilain]

On Tue, 2005-11-15 at 13:39 -0500, Andy Grundman wrote:
> Sam, I'm not sure why you only have ProcManager run if nproc > 1.  I 
> think running it with even 1 proc is a good thing, because you can HUP 
> the manager process to restart your application.  Do you see any harm in 
> always running ProcManager when -listen is specified?

The reasons for this are basically, I like to run my apps in the
debugger every now and then, so any forking at all is undesirable (it
either moans and doesn't work, or pops up another xterm, etc).

I didn't realise until now that FCGI::ProcManager does this when passed
nproc of 0 - so nproc = 0 should still be valid.  Also, perhaps it would
be a good idea to allow a ProcManager sub-class to be specified.  Given
it's very little extra work, perhaps it would be better, if passed an
empty process manager, to not use one at all.

> I also want to add a written pidfile for scripting purposes, and figure 
> out how to get it to detach from the console.  Pidfile was easy:
> 
>      if ( $options->{pidfile} ) {
>          $proc_manager->pm_write_pid_file( $options->{pidfile} );
>      }
> 
> Do you have any ideas about how to get it to do a proper detach?

Sure, that's easy enough, see Proc::Daemon.  However, perhaps all of the
things that Proc::Daemon does are not entirely appropriate for all
Catalyst applications.  Like, chdir(/), closing all file descriptors
(some of which could be open DB socket connections, etc).

Also, you can pass in the pidfile to the constructor; that way it
removes it after it has been killed.

So, the attached patch does all this.

Of course turning Catalyst into a daemon opens the sticky issue of
logging.  STDOUT and STDERR are detached, so you *could* regard any
logging that would send stuff to those filehandles as an error.  ie,
refuse to start without a suitable logging class enabled.

You know, looking at FCGI::ProcManager, there's nothing there that's
really FastCGI specific, so this module could work just as well for the
Server Engine.  OTOH, FCGI::ProcManager also does some annoying things
like change the process title to something completely generic, without
allowing it to be specified as an object property - you have to
sub-class it.  It also doesn't spawn new processes as it needs to - it
just keeps N in a pool, and re-forks when they die.  So, I'm thinking
that something a tad more sophisticated, drawing from FCGI::ProcManager
and based on ResourcePool might be better.  If another module then was
written to wrap that and provice a FCGI::ProcManager API, it should be
possible to drop it in to Catalyst (with the patch).

As a seperate note, the generic parts of Catalyst::Engine::Server should
be factored out, so that ::FastCGI doesn't have to re-invent them.  Some
important parts are missing, like the debug output.

Sam.