Hello,
On Monday 19 December 2005 04:18, JT Smith wrote:
> Apache is the ultimate event handler. It's listening for socket events. Why
> couldn't we change it just a bit to listen to timer events and thusly kick
> off an execution once per minute to check a cron tab. The reading of cron
> tabs is the easy part (DateTime::Cron::Simple for example). What would it
> take to just just get Apache to handle events other than a socket request?
> Is it possible? Of course it is, presumably it already knows how to handle
> signals. If it couldn't, there wouldn't be a way for us to issue a SIGHUP
> to do a soft restart. So, how do we get it to also handle timer events?
>
> Any ideas?
I investigated the signal approach with MP1 for a client of mine, and it is
feasible. The idea was to build a queue system that was able to accept
messages via HTTP and used signals to wake up a child dedicated to delivery.
Here it is a simple piece of code to stuck an Apache child in a loop and
control it via signals (USR1 and USR2). We used it as a PerlLogHandler.
package Test::ChildLoop;
use Apache::Constants qw(OK DECLINED);
use strict;
my $usr1 = 0;
sub catch_usr1 {
my $signame = shift;
$usr1++;
warn "Somebody sent me a SIG$signame";
return;
}
$SIG{USR1} = \&catch_usr1;
my $exit = 0;
sub catch_usr2 {
my $signame = shift;
$exit++;
warn "Somebody sent me a SIG$signame";
return;
}
$SIG{TERM} = \&catch_usr2;
sub handler {
my $r = shift;
my $count = 0;
while (not $exit) {
warn "child $$ waited for $count seconds and got $usr1 usr1 signals\n";
sleep 5;
$count += 5;
warn "hey, we got a shutdown\n" if $exit;
}
return OK;
}
1;
They ended using a modified version of Postfix, so I didn't investigate
further on, but I'm still interested in this approach.
HTH, Valerio
