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

Hi brothers,

I tried to understand fork. I think that I basically got the
theory behind it, but am far away from practical usage of this
nifty feature. What do I want to achieve? I want to simply harness
the power of SMP machines - just use all the nice BogoMIPS for
computational intensive tasks.

My first shot at it was Parallel::ForkManager:

use Parallel::ForkManager; # Yadda yadda
local %hash;
$pm = new Parallel::ForkManager(2); # Want use 2 CPUs now (###)

foreach $thingy (@so_30_member_list) {
  my $pid = $pm->start and next;  # (###)
  $hash{$thingy} = &big_heavy_computation_of($thingy);
  $pm->finish; # Terminates the child process (###)
}

&look_at_hash;

[download]
While this is really great because the loop just takes half
of the time to compute, it is not so great, because the hash
is very empty then. If I remove the (###) lines, the program
takes twice as long, but the hash is ok.

So now for me to better understand this. I assume, that with
the $pm->start and next a new child is forked with
completedly his own data, thus filling his own instance
of %hash, and then ... well ... just discarding it.

This isnīt actually what I want. How can I get the computer doing
what I want and not what Iīm telling him? :-)

Any help apreciated

Ciao

Replies are listed 'Best First'.
Re: FORRRRRK again...
by busunsl (Vicar) on Jun 28, 2001 at 14:50 UTC
[reply]
Re: FORRRRRK again...
by holygrail (Scribe) on Jun 28, 2001 at 17:29 UTC
    The Perl Cookbook lists a nice example how you can share variables between a parent and childprocess, but you couls also set up a named pipe or just use the IPC-modules...

    --HolyGrail
[reply]
Re: FORRRRRK again...
by PetaMem (Priest) on Jun 28, 2001 at 17:37 UTC
    Hi,

    thanks for your answers. I immediatedly dug into IPC::ShareLite
    and tried it and it works. However - itīs not what I need the
    children just need to do compute intensive work - and after that
    there is no need for the children anymore. So perhaps what I need
    is more of a client - server communication, where the clients
    (child-processes) are doing the computations, then sending about
    1kB of data to the server(parent-process) and terminate themself
    the parent process stores this data in a hash.

    There is really no need for really "sharing" this information
    just distributing work and then collecting the results.
    I would like to stay at the fork-based approach, because threads
    seem instable now, and because with Mosix (www.mosix.org) it
    will be possible to even distribute this task on a beowulf
    cluster - i hope.

    Ciao

[reply]
      Hi there fatvamp,

      It sounds like what you really need to do then is just set up a bidirectional pipe, fork, test to see if the process is the child or the parent, then close the side of the pipe that will not be used (writing for parent, reading for child). This is very textbook... so much so i stole it out of network programming with perl.

      Sample code follows: 

      use strict;
pipe (parent, child) or die "Can't open pipe: $!\n");
if (fork == 0) { #Test to see if parent or child
     close parent;
     select child;
     $| =1;
     #do your stuff here output should be written to parent
     exit 0;
}
#If we get here we are the parent process
close child;
print while <parent>; #this is to show the output coming from the chil
+d you should then store this data to your prefernce.

exit 0;

      [download]

      If the above does not allow smp functionality then use the parallel module again and then open a bidirectional pipe to the main process.

      Dave -- Saving the world one node at a time

[reply]
[d/l]
      Just a quick question on that. Why do you need the child processes to die after they report? I wonder if it may be easier to fork off X children that handle input from the parents in a more generic way, do the work, report back the findings, and stay alive waiting for the next job to do. If you were sure you wanted the child to die then sometime in the future, you could obviously include a kill command to send it.

      Just a thought. May or may not be any easier or cleaner. Just something I now think about with child processes now that I *have* to do it to make forked processes work with Perl/Tk. (see this node Re: IPC, trying for have child wait for commands)

      Justin Eltoft

      "If at all god's gaze upon us falls, its with a mischievous grin, look at him" -- Dave Matthews

[reply]

Back to Seekers of Perl Wisdom