"Bob McConnell" <r...@cbord.com> wrote on 03/05/2010 08:22:23 PM:
> The way I read his problem description, it sounded neither simple nor
> easy.
Bob, Jay,
I fear, Jay, my explanaitions weren't fully able to depict what my app is
trying to archieve. It is not only a matter of IPC on one machine that
happens to run tasks on other computers; actually, I have both IPC and
Socket operations there. Perhaps that's why you wrote the warning about my
terminology.
First of all, there is exactly one "master" program on a master machine.
This master program has a master process that is responsible for reading
commands in a not further described way (may be a script, a perl subclass
or an instance of Term::ReadLine). I've a "ProtocolHandler" role and
several concrete protocol classes that take care of parsing the commands.
There's also a class called "Dispatcher" that does the management work,
that is, instanceating classes and calling methods based on what the
Protocol parsed.
At this point, I need to introduce parallel work: Most of the work is done
on another machine, be it running dd, setting some option or starting
tcpdump. I call them "Commands" and created the Command role and several
classes. This parallelism is archieved by spawning subprocesses (I
refrained from the idea of using interpreter threads for some reasons).
Error/return codes, output and other stuff is neatly wrapped in such a
class performing the Command role. The reason I introduced this role is
not only to gather all stuff in one place, but also because what I call a
"command" can actually be a bunch of real commands or Perl function calls.
Introducing this layer of abstraction helps me with the management stuff
in the Dispatcher.
Now the same code base lives also on several "slave" machines, except for
a script that does some specific initialization work. Here, too, runs an
instance of a Protocol class, and the Dispatcher. The only difference is
the concrete Protocol class, which now uses Sockets instead of a (e.g.)
Term::ReadLine interface.
Now IPC comes into play at that point: Some sub-processes depend on
others. When I'm creating some kind of load on one machine and monitoring
the network activity on another, I'll want the network monitor stop as
soon as the load generator stops. The Dispatcher takes care of that, using
a Command called "Kill".
Finally, results get transferred back to the master that analyzes them
using some other scripts I wrote and, for example, puts a nice report
together.
You see, there's IPC on the local machine and possibly sockets to a remote
machine.
I'm going pretty well with that right now. :-)
There's only one thing that concerns me, although I haven't run into any
problems right now: Safe (aka deferred) vs. immediate signals. When using
Term::ReadLine to read commands, signals won't be handled until somebody
at least presses enter. This, however, means that the whole dependency
system doesn't work as I want it to, because another process isn't killed
when the first one exits, but after somebody pressed enter. I currently
circumvent the problem using the "POSIX" package's RT signals, but from
what I learned from perlipc, these signals aren't safe and can lead to
corrumption. Now "perlipc" doesn't give a concrete example on that topic.
I don't want to do much in the signal handler, but there's some work I
cannot avoid (e.g., flushing command output on SIGTERM, that, in turn, can
be issued because of a SIGCHLD -- the dependency stuff). Could somebody
please give me an example in which -- using POSIX RT signals -- work in
the signal handler is responsible for corruption, or better yet, outline
when corruption is very likely to happen, and why?
Thanks very much in advance,
Eric
--
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/
