Jeremiah Foster <jerem...@jeremiahfoster.com> wrote on 03/03/2010 02:09:40 PM: > 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.
Jeremiah, thanks for your answer. I fear my writing was misleading in regards of threads/subprocesses, sorry for that. One intention of my question was to find out whether the best way was to use Perl's interpreter threads or its fork() implementation. Your answer pushed me in the direction of using fork(), because I can then use the SIGCHLD handler to send a signal to another sub-process to solve my dependency problem. Dumping the stuff on the disk and reading/parsing it later also prooved to be good push in the right direction; I'm using FreezeThaw for that, together with IO::Compress::LZMA in case I expect a lot of data. Subprocess control on remote machines is now implemented using a simple RPC-like architecture, with JSON for data transport. I designed my Moose classes in a way that they are not aware whether they've been called locally or remote, a Dispatcher class takes care of that and also controls my processes. It all works pretty well now. Thanks! Bob, what language would you have used? I admit this is my first Perl project to involve this kind of child process handling. -- Eric MSP Veith <eric.ve...@de.ibm.com> Hechtsheimer Str. 2 DE-55131 Mainz Germany IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Erich Clementi Geschäftsführung: Martin Jetter (Vorsitzender), Reinhard Reschke, Christoph Grandpierre, Matthias Hartmann, Michael Diemer, Martina Koederitz Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 14562 WEEE-Reg.-Nr. DE 99369940 -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
