Re: Fork/Spawn

This is helpful; a few more refinements to my question:

The return order doesn't matter very much; as long as I can pass something unique to each process ($item in my example, $x in yours), I can use that to produce output that identifies who it came from.

Is there a way to gather the collective output using a variable rather than a temporary file? Is there any good reason not to just append to a string (like $output in my example?)

Lastly, I need to be able to limit the life of the child process; if the search takes too long or something else happens, I need to be able to kill it off. I can probably find examples of this somewhere, but it would be useful to have an example from someone who already knows my problem space.

Thanks for your help.

Comment on Re: Fork/Spawn

Replies are listed 'Best First'.
Killing Child Processes by chromatic (Archbishop) on Mar 29, 2000 at 03:53 UTC
The best way I know of to do the latter is not specifically documented in perlipc. Use alarm: `alarm 10; # send me a signal in 10 seconds # do some code which may not complete alarm 0; # if we get here in time, disable the alarm` [download] If you're going to fork off children, be sure to read the section on SIGNALS in perlipc. You might even do something like this, in your child processes: `eval { local $SIG{ALRM} = sub { die "child process took too long to compl +ete" }; alarm 10; # do whatever your little heart desires, hope it's fast enough alarm 0; # whew, just made it }; if ($@ && $@ !~ /alarm clock restart/) { # abort the child process gra +cefully } else { # send the parent the information ? }` [download]	[reply] [d/l] [select]
RE: Re: Fork/Spawn by btrott (Parson) on Mar 29, 2000 at 02:12 UTC
Have you looked at perlipc? It has some very useful examples of using pipe and fork to do bi-directional communication between a process and "itself." Another option would be to use socketpair (this is also described in perlipc). Yet another option would be to write a client/server app using sockets; you can set up a server that has the list of files to search, then set up some clients that communicate via sockets with the server. The server sends a filename to a client, and the client searches it, then sends back the results over the socket. You wouldn't need to use temporary files in any of these implementations. Just some ideas. Definitely take a look at perlipc.	[reply]