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