[eric@lenio.net: Event.pm usage]
Joshua N Pritikin
----- Forwarded message from Eric Lenio <er...@lenio.net> -----
From: Eric Lenio <er...@lenio.net>
To: jpri...@pobox.com
Subject: Event.pm usage
Hi Joshua,
I'm not new to Perl but I am to Event.pm. I read the tutorial that comes with
Event.pm but I'm still a little unclear if it can fit my need.
I'm writing a Perl app which heavily uses DBI.pm. What I want to do is handle
other arbitrary events (mainly user keyboard input) while a time-consuming
piece of SQL is running. I'd rather stay away from forking/threading (DBI
doesn't really support threads anyway).
At first I thought I could watch a variable until it received the result of the
SQL return code, but upon further thinking I don't think I can concurrently
process user keystrokes... am I correct? Any suggestions?
thanks,
Eric.
Uri Guttman
JNP> Does anybody have any suggestions beside threads?
JNP> ----- Forwarded message from Eric Lenio <er...@lenio.net> -----
JNP> From: Eric Lenio <er...@lenio.net>
JNP> To: jpri...@pobox.com
JNP> Subject: Event.pm usage
JNP> I'm not new to Perl but I am to Event.pm. I read the tutorial
JNP> that comes with Event.pm but I'm still a little unclear if it can
JNP> fit my need.
JNP> I'm writing a Perl app which heavily uses DBI.pm. What I want to
JNP> do is handle other arbitrary events (mainly user keyboard input)
JNP> while a time-consuming piece of SQL is running. I'd rather stay
JNP> away from forking/threading (DBI doesn't really support threads
JNP> anyway).
JNP> At first I thought I could watch a variable until it received the
JNP> result of the SQL return code, but upon further thinking I don't
JNP> think I can concurrently process user keystrokes... am I correct?
JNP> Any suggestions?
bacause you don't have direct access to the dbi socket (you can find it
with some flavors of db libs and dbi) you can't do an event on
it. watching a variable is basically polling and will burn your cpu
unless you put sleeps in but then you will kill response time to the
keyboard. and we all know threads are out. so the only proper solution
is to fork off a child process and run dbi in there and let it block
normally. you can then send dbi commands and get results over the pipe
(you did make a pipe before forking? :) to the dbu process. lucky for
you, two systems which run over event.pm already do this. one is stem
(stemsystems.com/Stem-0.11.tar.gz which is in beta release now) and poe
(poe.perl.org). they both have standard way to run dbi in a subprocess
and make it look like it is local to your main event process which is
running the event loop (commonly event.pm but other event loops are
possible).
as an aside, a long time ago i did an event loop system (in C) which
used sybase. we picked sybase for several reasons, one of which that it
gave us direct access to its socket in its client lib and we could
select on it and just call the sybase lib to handle and return the
results. this way we were able to make 10 parallel connections to sybase
from our single process (which could handle up to 2k users). sybase's
throughput increased with each connection until it maxed out at about
10. we could have created another process layer to handle blocking but
this was much easier and worked well. but few db libs work that way and
with dbi in the way it is all but impossible to do anyhow.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org