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

sgfifford, that's really the heart of my question -- is it incumbent upon the module user or author to check for and work around this? I normally have little sympathy for module users -- if you are willing to accept the benefit of someone's code, you should accept the burden of playing by its rules -- but in this case, I was using MIME::Entity, which used Mail::Internet, which used Mail::Mailer -- nowhere in MIME::Entity's API was it clear that a fork would be happening.

Based upon what I've heard in this node and elsewhere due to this experience, I now beleive that CPAN modules that use fork(), open-to-pipe, or similar calls MUST account for the possibility of being called inside an eval -- or else document that the code MUST NOT be called inside an eval without checking for a fork gone wrong.

I don't believe this is especially burdensome to CPAN authors, because the patch to Mail::Mailer that solved this problem was only a few lines of code (most of which were splitting out a logic condition into an if/then/else). Am I on the wrong track here?

  • Comment on Re^2: forked die() in eval block has counterintuitive behavior?

Replies are listed 'Best First'.
Re^3: forked die() in eval block has counterintuitive behavior?
by sgifford (Prior) on May 24, 2005 at 15:05 UTC
    No, I think you're right, though if you plan to find and fix every forking bug in CPAN you certainly have your work cut out for you. And regardless, defensive programming would mandate that you check for the fork condition in your calling code.

    It would be interesting to take this to the perl5-porters list and see their take on it.