[Speedycgi-users] Re: Catching end of process / shutdown handler

[PW <sub...@me...>]

Hi Sam

Thanks, works perfectly utilized as shown below! I was not aware that
you could mix both modules together.


	(defined $s{OS} && $s{OS}) || init_constants();
	# ... your main routines ....

sub init_constants() {
	$s{OS} = $^O;
	sub shutdown_process {
	   .... your cleanup routine ....
	}
	if ( eval { require CGI::SpeedyCGI } && CGI::SpeedyCGI->i_am_speedy ) {
    	   CGI::SpeedyCGI->add_shutdown_handler( \&shutdown_process );
	}
}


Philippe Wiede
megapublic inc.


Sam Horrocks wrote:
> 
> You should be able to do this with a shutdown handler.  The perl
> interperter backend is the same whether you use "mod_speedycgi" or
> "speedy" as the frontend.
> 
> Here's a test script.  Put this in your mod_speedycgi directory and
> run it by doing an http request.  Five seconds later, a file named
> "/tmp/data" should show up when the backend times out and shuts down.
> 
> #!/usr/bin/speedy -- -t5
> use CGI::SpeedyCGI;
> sub save_data {
>     open(F, ">>/tmp/data"); print F "data\n"; close(F);
> }
> BEGIN {
>     CGI::SpeedyCGI->add_shutdown_handler(\&save_data);
> }
> print "Content-type: text/plain\n\nhello world\n";
> 
>  > Folks
>  >
>  > Is there are way to catch the end of life of a SpeedyCGI front-end
>  > process? What I am looking for is sort of a shutdown handler like the
>  > SpeedyCGI CGI module provides, however I am utilizing the SpeedyCGI
>  > Apache module which does not provide this functionality. Obviously, END
>  > blocks are ignored in a persistent environment and trying to do it via
>  > signal handling seems a little hairy if not unreliable.
>  >
>  > As a specific example: a CGI app uses session tracking, keeping the
>  > session data as a per process hash persistently in memory. If the
>  > process dies due to inactivity, max runs or whatever, it should perform
>  > one last clean-up job, i.e. flushing the remains of the session data to
>  > disk. Of course, one could store or tie the session data on each
>  > invocation to disk, loosing some efficiency, but I want to reap the
>  > benefits of persistency!