>>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> Some of this ground does need to be revisited, since perl 6 isn't going to
>> be perl 5, and the tradeoffs are going to be different. (I'm still not sure
>> that checking for pending events every opcode is the way to go, either.
>> Piggybacking on the end of statement cleanup opcode might be a better
>> place, depending on how frequently that happens)
JH> That might also be a more logical place: then we could say that a
JH> statement is the 'atomic' unit. Yes, some statements take longer
JH> than others. Tough.
that would work too. even counting statements would work if you want
even less of a bite for event checking. as long as it is done between
ops we are safe. i am not concerned how often we check as long as it is
reasonable. the perl event system doesn't guarantee preemption nor any
latency. it should just guarantee safe signals and delivery of events and
async i/o.
we can easily play around with where we check for events. that is only a
couple of lines of code places in various locations. the event checking
guts will all be the same subsystem in all cases. we can make a pragma
the allows the user to select the latency (every N ops or every N
statements) so they can fine tune it. but as i have said before if you
are that much into events, then you would use a the proper event loop
yourself and have no extra slowdown anywhere in the op loop or at
statement end. that is the highest level tradeoff. do the delivery
managment yourself or pay a (minor) speed penalty if perl does it safely
for you. either way, perl should tightly integrate the event loop with
i/o and the op code/statement stuff.
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
