Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote: >>Event handling currently works for all run cores[1] except JIT.
> What I'd planned for with events is a bit less responsive than the > system you've put together for the non-JIT case, and I think it'll be > OK generally speaking. > Ops fall into three categories: > 1) Those that don't check for events > 2) Those that explicitly check for events > 3) Those that implicitly check for events Yep, that are the cases. I think I have boiled down that scheme to "no cost for non JIT run cores[1]", that is, in the absence of events there is no overhead for event checking. Event delivery (which I consider rare in terms of CPU cycles) takes a bit more instead - but not much. But the JIT core has to deal with event delivery too. So we have to decide which JITted ops are 3) - (case 2) the explicit check op is already available, that's no problem we need hints for 3) > Ops in the third category are a bit trickier. Anything that sleeps or > waits should spin on the event queue Ok, the latter is the simple part - all IO or event related ops. But the problem remains: What about the loop[2] of mops.pasm? Only integers in registers running at one Parrot op per CPU cycle. > The big thing to ponder is which ops ought go in category three. I > can see the various invoke ops doing it, but beyond that I'm up in > the air. Yes. First: do we guarantee timely event handling in highly optimized loops like in mops.pasm? Can we uses schemes like my proposal of using the int3 x86 instruction... leo [1] the switched core currently checks after the switch statement, but its not simple to optimize that [2] <jit_func+116>: sub %edi,%ebx <jit_func+118>: jne 0x81c73a4 <jit_func+116>