in reply to forked die() in eval block has counterintuitive behavior?

A die() occurring within a forked child process will get caught by a containing eval block in the parent.

This is incorrect. I ran your test program and I didn't see anything to idicate that you are correct. Here's the output I saw:

(PID 20379) Beginning transaction #123 at foo.pl line 6. (the child fails) at foo.pl line 13. (PID 20380) Rolling back transaction #123: died in eval with Child pro +cess failure at foo.pl line 14. (the parent does OK) at foo.pl line 10. (PID 20379) Committing transaction #123 at foo.pl line 21.

Clearly the eval{} is catching the die() within the child, not the parent.

However, the general thrust of your post is quite correct: it is very bad for a module to fork() and not document that fact. Debugging a fork gone wrong can be very hard, particularly if you don't know a fork() might have happened!

-sam

Replies are listed 'Best First'.
Re^2: forked die() in eval block has counterintuitive behavior?
by rlucas (Scribe) on May 24, 2005 at 01:31 UTC
    Yes. I misspoke; as the PIDs clearly show (and as my intention in including them was to indicate), the "catch" of the die() is in the child process.

    An unexpected child die() gets caught by a containing eval block that thinks it's just dealing with the parent.

    The overall problem, then, is as you state -- not knowing that a fork() has happened. Is there a general way, then, to deal with this in evals? It seems that the casualness with which fork()s are issued in various places makes this problem endemic to the idiom of Perl...

      An unexpected child die() gets caught by a containing eval block that thinks it's just dealing with the parent.

      I don't think this problem is specific to eval{}. Any code which is going to fork needs to be careful about which code is going to run in the parent and which in the child. It's just a fact of Unix programming, not really a problem with Perl specifically.

      -sam