>>>>> "JH" == Jarkko Hietaniemi <jhi@iki.fi> 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 --------- uri@sysarch.com ---------- 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.comThread Previous | Thread Next