>>>>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> This is the Perl interpreter:
SC> while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
SC> PERL_ASYNC_CHECK();
SC> }
SC> The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
SC> do anything. :)
SC> Just for fun, I once took that out and replaced it with a fully-featured,
SC> signals-aware, prioritizing event loop.
SC> 5x slowdown.
not if you just check a flag in the main loop. you only check the event
system if you have pending events or signals, etc. the key is not
checking all events on each pass thru the loop. you don't even have to
check every pass if you use my counter idea. at some point in the loop
you have do to a full select/poll setup and process its results. you
don't do that every time thru the loop. that is where the counter
wins. 1 of N passes will be greatly slowed down.
now, for perl programs written to be in an event loop like any g?tk or
POE or event.pm or stem system, having the core of perl be an event loop
is a big win. also the ability to do all of these async things from both
perl and in the guts is big. you just have to avoid the large slowdown
that doing a full poll every loop pass causes.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
