[Phoenix-pm] greetings
Metz, Bobby W, WCS
bwmetz at att.com
Tue Jul 27 23:05:26 CDT 2004
As neither I nor my colleagues have root access to compile
modules and the sysadmins are really freakish about keeping their Perl
dist unchanged as many "accepted" tools might break, we've developed all
of ours using our own modules, relying on system utilities to make the
SNMP calls instead of an established SNMP module from CPAN. Until
recently we were even lead to believe that there were no compilers
loaded on the box. I recently found one so we could compile our own
library for use but we've ran into some problems with the compiler on
some CPAN modules and really weren't looking forward to rewriting
everything anyway.
So, is there anyway to accomplish what I'm looking to do without
using Coro or some other module? If the "action" code is modularized,
could I simply fork these instances to run concurrently while either
passing back output to the calling routine or all writing to the same
set of error files? I just wasn't sure how Perl would handle such a
situation.
Thanks for the feedback.
Bobby
-----Original Message-----
From: Scott Walters [mailto:scott at illogics.org]
Sent: Tuesday, July 27, 2004 5:16 PM
To: Metz, Bobby W, WCS
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] greetings
What module exactly are you using? Things that lend themselves well to
threads usually lend themselves well to coroutines as well, with one
exception - if you're trying to use two modules, each of which has their
own event loop, coroutines don't directly work - you have to break
the event loop down. (If a module supports the Event module for a
communal
event loop, Coro has glue into Event, so this works).
For example, if you're using Net::IRC with Tk, and Net::IRC wants you to
call
Net::IRC::start to hand over control of the program and Tk wants you to
call
Tk::MainLoop to give up the CPU, you have a delimma. Threads solve this
by
creating additional "virtual CPUs", wheres coroutines only help you
juggle your
one CPU. You'd have to extract the relavent filehandles, build your own
Event loop using Coro::Handle::unblock or Coro::Event::io, and then call
the
do_one_loop() loop in Net::IRC and the equivilent in Tk to do a single
pass through
their private event loops without giving up control of the CPU.
Modules that don't have an event loop at all work great - they don't try
to
hold onto the CPU indefinately. So, it depends on the exact module
you're using =)
-soctt
On 0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
>
> Hmmm...these all sound interesting so maybe I should ask a pointed
> question now. I do a lot of net admin stuff involving SNMP polling
and
> currently most of my tools are "single-threaded", i.e. I poll one
device
> at a time. Based on the options presented, what would be the easiest
> means of changing to a setup of polling say 10 devices at the same
time
> with the main script retaining control and reporting responsibilities?
>
> Thanks,
>
> Bobby
>
> -----Original Message-----
> From: phoenix-pm-bounces at pm.org [mailto:phoenix-pm-bounces at pm.org]On
> Behalf Of Anthony Nemmer
> Sent: Tuesday, July 27, 2004 7:44 AM
> To: Scott Walters
> Cc: phoenix-pm at pm.org
> Subject: Re: [Phoenix-pm] greetings
>
>
> Unix pipes implement a kind of coroutine chain of unix commands.
>
> Scott Walters wrote:
>
> >Well, coroutines are a lot like POE (or Event, or Stem), except
> >when the event happens, rather than another routine being called, the
> >current is allowed to continue. This means that you don't have to
> >tuck all of your variables into an object to preserve them,
> >and you don't have to return out of for() loops, if() statements,
> >deeply nested function calls, and so on... but the POE stuff
> >about not shooting yourself in the foot with threads still
> >applies. And no special version of modules are required,
> >as with threads.
> >
> >Here's a little script tht demonstrates continuations:
> >
> > use Coro;
> > use Coro::Cont;
> >
> > use File::Find;
> > use Perl6::Variables;
> >
> > sub get_next_perl :Cont {
> > find(sub {
> > return unless m/\.pl$/;
> > open my $pl, '<', $_ or return;
> > (my $shebang) = <$pl> =~ m/^#!(\S+)/ or return;
> > yield $shebang;
> > }, '/');
> > return undef;
> > }
> >
> > while(my $_ = get_next_perl()) {
> > last unless defined $_;
> > print $_, "\n";
> > }
> >
> >This tries to find all of the Perl itnerpreters on your system that
are
> >in use. Coroutines are used to create detached processes and
> continuations
> >are used to create closely coupled processes. In this case, control
> >flops back and forth between get_next_perl() and the while(). Even
> >as control flops back, the lexical variables inside get_next_perl()
> >keep their value. More importantly, the call to File::Find::find()
> isn't
> >exected out of. It would suck if that had to be restarted each time
> >we wanted to know what interpreter the next file used. Likewise with
a
> >network application, this would be responsive, whereas storing
> everything
> >in an array and returning a reference would wait a really long time
and
> then
> >suddenly have a whole bunch of data.
> >
> >Hrm. I should write some examples of gluing POE to Coro. Event
handler
> stubs
> >could execute a ->transfer() to transfer control to a specific
> coroutine.
> >I wonder how Coro::Event does it...
> >
> >-scott
> >
> >On 0, Artful <ahenry-pm at artful2099.com> wrote:
> >
> >
> >>>Anyone into multi-threaded perl programming? It's something I have
> no
> >>>experience in and would love to see an overview if anyone is
willing.
> >>>Just a thought.
> >>>
> >>>Bobby
> >>>
> >>>
> >>Threading in perl is cumbersome at best. I am falling in love with
> POE.
> >>http://poe.perl.org/
> >>
> >>At first glance, it can seem complex, but the concept is pretty
simple
> and
> >>it is easy to pick up. There are a couple of recent articles at
> perl.com
> >>covering it: http://www.perl.com/pub/a/2004/07/02/poeintro.html and
> >>http://www.perl.com/pub/a/2004/07/22/poe.html
> >>
> >>-Art-
> >>_______________________________________________
> >>Phoenix-pm mailing list
> >>Phoenix-pm at pm.org
> >>http://www.pm.org/mailman/listinfo/phoenix-pm
> >>
> >>
> >_______________________________________________
> >Phoenix-pm mailing list
> >Phoenix-pm at pm.org
> >http://www.pm.org/mailman/listinfo/phoenix-pm
> >
> >
> >
> >
>
>
> --
>
> SKYKING, SKYKING, DO NOT ANSWER.
>
>
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://www.pm.org/mailman/listinfo/phoenix-pm
>
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://www.pm.org/mailman/listinfo/phoenix-pm
More information about the Phoenix-pm
mailing list