Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^2: Eval/Fork lesson of the day

by Anonymous Monk
on Jan 21, 2016 at 21:18 UTC ( #1153324=note: print w/replies, xml ) Need Help??


in reply to Re: Eval/Fork lesson of the day
in thread Eval/Fork lesson of the day

Thanks for this article, I found it quite useful. I ran into this when writing a test for a package I wrote to ensure that it properly bombed with tainted data. The package wrapped an Unix command, and forked.

I was quite confused when Test::Harness started showing duplicate results for the same test number (one passing and one failing:). Quite a bit of head banging until I could reduce the issue to something which lead me to google this article.

So I think this issue can crop up in some unexpected places.

Replies are listed 'Best First'.
Re^3: Eval/Fork lesson of the day
by Minok (Novice) on Sep 14, 2016 at 01:27 UTC

    So there is some side effect / memory sharing magic going on when the fork is inside an eval, clearly.

    Things work well when I'm running a loop over some cases and just fork (and have the forked children self monitor and die with error or die with success).

    When I had my forked child do the same thing but its within an eval, then I got the same sequence of loop iterations, but also got a lot of reinterpretition of cases the loop had already evaluated.

    What is it about being inside an eval that causes this fork oddity?

    The use of eval is handy to capture the die results in the parent and then log them.

      There is nothing magical going on here. You get the same problem if you just leave off the 'exit' from the code to be run by the child.

      The only trap that 'eval' allows here is that, if the child 'die's, then the 'exit' can be skipped. If there is no 'eval', then that causes no problem because the child still exits without returning to the calling code that is meant to only be run by the parent. But with an 'eval', the 'die', in effect, transfers control up to the calling code and you end up with both parent and child running the calling code.

      The only sharing is the standard sharing that happens when you fork. That is, the child gets a copy of (nearly) everything from the parent. Nothing is shared from the child to the parent (the exit status and resource usage is made available to the parent and output from the child can go to the same destination as the parent's output, of course).

      Does that clear the mystery up for you?

      - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1153324]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (8)
As of 2021-01-27 18:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?