From: Jeremiah Foster > On Feb 26, 2010, at 10:34 PM, Eric Veith1 wrote: >> >> I'm wrinting a perl program that works with different threads. > > Your first sentence already has me worried. Threads are un-fun. > >> Those >> threads depend on each other, not all in the same way. Some threads should >> stop when others are finished with their work, and again others are to be >> started afterwards. > > Now getting really complex. > >> I have six worker machines, M1 to M6, and a controller machine, M0. The >> perl program runs on the controller machine. This program is basically a >> dispatcher I control from a command line interface. A command causes two >> threads to be started, say on M1 and M2. > >At this point, these are really processes. Threads are in the kernel, you > are just starting a separate process on two different machines. > >> One thread on M1 produces work, >> the other on M2 plots the network traffic. When M1 is finished, I want the >> thread M0 that caused the workload to signal to the dispatcher that M1 is >> finished. The dispatcher then shall signal M2 to stop monitoring. >> Afterwards, I want the results from both M1 and M2, preferably in form of >> a perl structure. > > These are all separate processes, not threads. Are you sure you need to > use threads? In general a thread is something that runs _inside_ a > process. http://en.wikipedia.org/wiki/Thread_(computer_science) > >> First of all, is that possible? > > Yes. Not that hard. You have exit values from your process so you can > trap that and do something based on your exit value. >> >> I have already looked at threads, threads::shared and the traditional
>> fork(). With the standard IPC stuff, I'm able to signal and trap that in >> the master process with a signal handler. But I cannot, however, get the >> PID of the child that emitted the signal, thus I'm not able to send a >> SIGTERM to another process. I'm also not sure how I could get my result >> data. > > Well, why not just create something in a perl structure and just use > something like the Storable module or YAML to dump it to disk and you > can read it from your other machine. >> >> threads::shared allows me to share a perl structure I could fill, but I >> don't know how to signal the master thread. Passing a subroutine reference >> doesn't work, of other options I don't know. >> >> I'd very much appreciate any hints. > > I would avoid threads. I would have a program / process on machine 0 > that fires off another program / process on machine 1. Then I guess > you need to fire off your program on machine 2 to do network > monitoring (?). When the program on 1 is finished, it dumps its data > to disk and call machine 0 who in turn calls 2. Depending on how much control you have over development of this package, I would suggest a hybrid approach. First, launch an application which creates multiple threads to start up the individual processes. Open a communications channel between each thread and the process it called. Then use the threads to monitor and/or control the individual processes until they terminate. Once the process is done, terminate the matching thread. When processes run on the local machine, any of the IPC options can be used for the comm channel. On remote machines it is more likely to be a socket. Interprocess communications can be done either via IPC or relayed through the control threads. However, if the application is this complex, is Perl really the best language to use? It would not be my first choice. Bob McConnell -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
