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

Reply via email to