>>>>> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
JNP> Does anybody have any suggestions beside threads? JNP> ----- Forwarded message from Eric Lenio <[EMAIL PROTECTED]> ----- JNP> From: Eric Lenio <[EMAIL PROTECTED]> JNP> To: [EMAIL PROTECTED] 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 ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
