[Phoenix-pm] greetings

Scott Walters scott at illogics.org
Tue Jul 27 19:15:38 CDT 2004


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