Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^5: How does CATCH_SET optimize efficiency?

by PerlOnTheWay (Scribe)
on Dec 17, 2012 at 04:11 UTC ( #1009109=note: print w/replies, xml ) Need Help??

in reply to Re^4: How does CATCH_SET optimize efficiency?
in thread How does CATCH_SET optimize efficiency?

But FETCH is always called "from C", so the je_mustcatch is always true, and the eval ops will always create a new runops loop.

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

  • Comment on Re^5: How does CATCH_SET optimize efficiency?

Replies are listed 'Best First'.
Re^6: How does CATCH_SET optimize efficiency?
by dave_the_m (Prior) on Dec 17, 2012 at 15:54 UTC
    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, 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?

        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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1009109]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2018-03-20 08:39 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (248 votes). Check out past polls.