Re^2: Eval/Fork lesson of the day

[Anonymous Monk]

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.

[Minok]

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.

[tye]

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?