in reply to Eval/Fork lesson of the day

... I'm definitely going to be in the habit of putting all forked code in some sort of eval block to make sure that I can safely wrap the forking code in another eval block...

... or maybe you'd look for other ways to get the job done without having to use "eval { ...fork... }" in the first place. I'm no jedi when it comes to fork, but I know it well enough to respect it, and this is the first time I've seen anyone put a fork call inside an eval block. Just curious... what situation could make this a preferred approach?

Replies are listed 'Best First'.
Re: Re: Eval/Fork lesson of the day
by lestrrat (Deacon) on May 15, 2002 at 16:03 UTC

    The basic premise was that I needed to catch all errors from a series of steps, and if there were any errors in the middle, I needed to do whatever to undo the changes:

       while(1) {
      eval {
         do_this();
         do_that();
         fork_and_stuff();
         and_why_not_do_this_as_well();
      };
      if( $@ ) {
         undo_changes();
         log( "there was, like, something wrong: $@" );
      }
   }

    [download]

    It just so happened that one of the subs actually forked, and hence the problem. I wasn't trying to eval the fork() per se... ;)

[reply]
[d/l]
      That makes sense, but it does look a bit tricky. So, I assume you would really want to hit the "undo" block if the fork fails; and maybe you would want to make sure the fork call is the last step in the eval block, so that if any of the other steps fail, you could save yourself the trouble of forking before undoing things.

      When the fork "succeeds", then any problems encountered by the child will be asynchronous with respect to this process, right? And that might make it hard to "undo" whatever the child does, I think. (I'm sure there's a way to deal with that, but as I said, fork is not one of my strong suits.)

[reply]

In Section Meditations