>>>>> "n" == nick <[EMAIL PROTECTED]> writes:
>> a single test flag which is set by a
>> variety of events is all that is needed. but we also should have an op
>> loop with no test as the code could use an event loop to handle all
>> events. then dispatching is not done inline. would it be worth it for
>> the speedup to have 2 different op code loops?
n> I doubt it - but we may as well have "plugable" loop (as in perl5)
n> just in case.
well, if we only have a single flag to test, then it won't be much
overhead. inside that conditional we do the real work.
>>
>> also do you want to test each time thru the loop? what about a counter?
n> Explain your counter idea some more (I will _read_ rather than skim
n> the RFCs one of these days...)
n> It seems to me that decrementing counter is extra inner-loop cost,
n> and you still have the conditional branch delay when you test
n> counter value, you might just as well test the "flag".
well, it can be done in several ways and none are too well thought
out. here is one rough idea:
while( op = next_op() ) {
op->execute() ;
if ( event_flag ) { # SOME event is pending
if ( --event_dispatch_counter <= 0 ) {
dispatch_all_events() ;
# that will cause a recursive call to this loop!
event_flag = 0 ;
event_dispatch_counter = event_counter_init ;
}
}
}
that is so we don't dispatch events between every op code. i think that
would cause too much overhead. instead we do it every N op codes. this
is not a critical issue. the single flag in the loop is much more
important.
NOTE: the event dispatch call will eventually recurse to the op code
loop to execute the event handler. is there an issue of dispatching
events inside a dispatch call? there shouldn't be any and we have to
make sure of that. all code at this level must be very clean and
reentrant up the wazoo. :)
also some events will be handled internally (read ahead, initial async
i/o handling, etc.) and then possibly dispatched to perl level handlers.
this is more likely to be used when code generating inline checks. every
Nth op code would be a event_check_op. this has a weakness of what if
you have a very tight perl loop that doesn't exceed N ops? will events
ever get dispatched then? the op loop counter method works better there.
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
