http://qs1969.pair.com?node_id=142336

c has asked for the wisdom of the Perl Monks concerning the following question:

i'm having some issues with subroutines being ran on a forked process. the subroutines have print statements which i would like to have printed to stdout in a format similar to:
"\nthis is my message\n\n"
however, the print format is not as controlled as it is when i do not fork. sometimes my command line is returned before the final print statement in the loop. i'll see my first three prints, and then my command line prompt, with the fourth print statement appearing after the prompt.

do i need a wait() statement? and if so, where? i'm not too familiar with the function. thanks -c

my code:

#!/usr/bin/perl -w use strict; ## declare a pid for forking my $pid; ## loop through devices for my $node(@devices) { ## if child process exists, move to next device if ($pid = fork) { next; ## begin actions within the child process } elsif(defined($pid)) { ## print a message &log_action($node); ## explicit exit for child process exit; } else { die "Cant fork for some reason! : $!\n"; ## endif } ## end of for loop } sub log_action { my $i = shift; print "\nThis message if for node $i.\n\n"; }

Edit by tye to remove tons of trailing spaces from lines

Replies are listed 'Best First'.
Re: Understanding how to fork properly.
by jepri (Parson) on Jan 31, 2002 at 02:37 UTC
    There's nothing going wrong, just your expectations are a little off. When you fork, you are spinning off all new, real, full programs. They execute (almost) independently of your initial program. Ever heard the phrase 'fork and exec'? It's how you start a daemon.

    So in your case, everything happens the way it should. However, one of your forked children prints after your parent program quits. You weren't expecting this, but it is fine.

    You are slightly confused because you expect your command shell to wait until all the children finish before giving you a command prompt. However command shells only wait for their immediate children to exit. They can't know about their childrens children ( how could your program find out if the children it makes make their own children?)

    You should be waiting for your children to exit, but the consequence of not waiting is zombie processes, not out-of-order output.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

Re: Understanding how to fork properly.
by particle (Vicar) on Jan 31, 2002 at 02:39 UTC
    you might want to try setting $| to some non-zero value. $| causes a buffer flush after every print statement (i think it works for write, too, consult the camel.)

    most people write $|++;, but i prefer explicitly setting $|=1;. that way if some bonehead set it to -1 previously, the increment op wouldn't be doing the wrong thing.

    oh, and this works by default on STDOUT. you'll have to specify autoflush on other filehandles by selecting them first, or by calling the autoflush method on the filehandle, something like $FH->autoflush();

    ~Particle

      if some bonehead set it to -1 previously, the increment op wouldn't be doing the wrong thing.

      Oops! No. $| is magic. It always equals either zero or one. Nothing else. Behold:

      print "$|\n"; # 0 $| = -1; print "$|\n"; # 1 $|++; print "$|\n"; # 1 $|++; print "$|\n"; # 1 $|--; print "$|\n"; # 0 $|--; print "$|\n"; # 1 $|--; print "$|\n"; # 0
      As you can see, $|++ always sets $| to one (no matter what it was) and $|-- always toggles it.

      ------------------------------------------------------------
      "Perl is a mess and that's good because the
      problem space is also a mess.
      " - Larry Wall

        The Camel is a much more effective and satisfying LART than a hard drive, a monitor, or the full-sized server. Hey, if I've spent five minutes reeducating the guy, I don't want him to lose it with a concussion!
        it's a visceral thing for me. when i need to look something up quickly, i turn to books before i search online docs. every time. i like the feel of paper.

        i also prefer the index as search tool. maybe if there were good indexes online, not tables of contents and search tools, i'd look online more.

        i always travel with the camel. my copy is pretty beaten up, as it's seen thirty states in the past year alone. i suppose you could call it my perl security blanket :)

        ~Particle