>>>>> "Rob" == Rob Bloodgood <[EMAIL PROTECTED]> writes:
[...]
Rob> Is there any code that is NOT under NDI you could send me, to
Rob> demonstrate?
There was talk about getting some sort of POE patterns page
set up. I was going to try and abstract out this (helpers for
non-preemptable stuff) and submit something for that. I'll try and
see what I can do.
But for now, the helper subroutine (which is called
Damage::DBHelper::db_helper) is basically the following:
[...]
$| = 1;
my $dbh = DBI->connect( $config->dsn, $config->dbi_user, $config->dbi_pass )
or die "Can't connect to " . $config->dsn . ': ' . $DBI::errstr . "\n";
my $sth = $dbh->prepare( q{ select blah blah blah . . . } )
or die "Can't prepare SQL statement: " . $DBI::errstr . "\n";
my $res; # to hold DBI result
while( <STDIN> ) {
chomp;
last if /^EXIT$/; # allow parent to tell us to exit
my( $id, $rest ) = split( /\|/, $_, 2 );
unless( $sth->execute( $id ) ) {
print STDERR "## $$: error executing query: ", $sth->errstr,"\n";
print "ERROR|", $sth->errstr, "\n";
} else {
$res = $sth->fetchrow_arrayref;
print STDERR "## $$: db returned ", $res->[0], "\n"
if $config->debug->{damage_db} > 2;
print $res->[0], "|$_\n";
}
$sth->finish;
}
$dbh->disconnect;
[...]
And the main session class has the following method that it
uses to create helpers at startup time:
sub create_db_helper {
my $self = shift;
## Input and output from the children will be line oriented
my $filter = POE::Filter::Line->new(
InputLiteral => "\n",
OutputLiteral => "\n",
);
my $helper = POE::Wheel::Run->new(
Program => sub {
Damage::DBHelper::db_helper($self->config );
},
StdoutEvent => 'db_reply',
StderrEvent => 'remote_stderr',
ErrorEvent => 'error',
Filter => $filter,
)
or warn "Can't create new Wheel::Run: $!\n";
print "## Started db helper pid ", $helper->PID, " wheel ", $helper->ID, "\n"
if $self->debug > 2;
return $helper
}
(Oop, I just noticed a bug; $helper should be checked for
definedness in that last print before methods are called on it.)
The main _start handler saves off a queue of these helpers
which get used round robin (I just abstracted out a HelperQueue class
that handles keeping track of them this weekend; didn't take much time
to get working counting removing the old queue managment code I was
using).
The request is basically the thing we need to lookup in the
database and the wheel id for the socket connection on which the
corresponding request was received (so we can pair it back up when the
result comes back from the helper; but you don't necessarily need a
wheel id, just a unique token to identify the request when it comes
back). Both items are joined together with `|' as the seperator and the
request is put() to the next helper in line.
The db_reply handler splits the result back and posts another
event with the information on to another session (actually to one of a
different helper process pool which starts an openssl connection to a
remote host (because I hadn't gotten my SSLSocketFactory working
yet)).
--
Fletch | "If you find my answers frightening, __`'/|
[EMAIL PROTECTED] | Vincent, you should cease askin' \ o.O'
770 933-0600 x211(w) | scary questions." -- Jules =(___)=
| U
