Re^6: How does CATCH_SET optimize efficiency?

[dave_the_m]

Why not set up a new runops loop directly in the first place?

I'm not sure I understand you. When the tie magic code calls FETCH, it starts a new runops loop to execute the ops within the FETCH sub (but it doesn't do a JMPENV_PUSH). If the FETCH function doesn't do any eval-ly stuff, then that's it. If the FETCH does eval {}, then the first time pp_entertry is called, a second runops loop is started, and JMPENV_PUSH is done. The rest of the ops within that eval, and continuing outside that eval, are executed within the inner runops loop, including any ops within second and subsequent eval {}'s. Finally, when FETCH returns, two runops loops and a jump level are exited.

Dave.

[PerlOnTheWay]

Dave, thanks, this clarify things a lot!

So when there're multiple evals in a FETCH, and an exception is triggered, it will always restart from right after the first eval, no matter what, as only the first eval actually does JMPENV_PUSH, is it right?

[dave_the_m]

In something like

sub FETCH {
    eval { $x++ }
    $x--;
    eval { die }
    print;
}

The first eval pushes a new setjmp and runops loop. The inc, dec and die ops are executed within that loop. The die causes a longjmp, which unwinds the C stack, destroying the inner runops loop, and returns control to the exception handler set up by the first call to entertry. That code 'restarts' the op by calling runops(), which executes the print and any remaining ops in FETCH. When FETCH returns, runops() exits, and control is passed back (again) to entertry's exception handler, which this time just immediately returns, passing control to the the middle runops loop, which also immediately returns, and control passes back to the code which handles tied variables.

Dave.

[PerlOnTheWay]

So the net effect is that when there's no eval in FETCH, a JMPENV_PUSH is saved, but when there is eval, a run loop is wasted(3 vs 2), is this right?