[Phoenix-pm] greetings

Anthony Nemmer intertwingled at qwest.net
Tue Jul 27 23:39:14 CDT 2004


Don't you mean "Scrotorola" ???

Scott Walters wrote:

>Heh. I have a story I tell all too often =)
>
>I worked as a sysadmin at Motorola for a brief period of time. It was 
>there I was ordered to learn Perl (after lieing at the interview saying 
>I knew it). My first task was to write a script to find all of the Perl
>interpreters installed on the cluster that serves http://mot.com /
>http://motorola.com. The script traversed the entire filesystem
>and found 400 installs, about a third of which were Perl 4's (this was
>probably 4 years ago). Perl wouldn't be installed (and kept up to date)
>systemwide for "security reasons". So, instead of one potentially
>exploitable version for everyone, each person got a version that's
>not kept up to date and in a huge number of cases, exploitable.
>
>But this story has a point - you can install perl or any of the modules
>in your home directory or in some shared place. Assuming that perl
>itself is kept up to date and you just want to install a module, 
>ftp the .tar.gz from CPAN, and do something like:
>
>  tar -xzvf Foo-Bar-3.2.1.tar.gz
>  cd Foo-Bar-3.2.1
>  perl Makefile.PL PREFIX=/usr/local/share/departments/r_and_d/shared_files/mp3s/
>  make && make install
>
>Perl programs won't "see" this module by default as its in a place that perl
>wasn't told about when it was built (and it isn't in the default place to
>install modules), but you can easily tell perl about it by saying:
>
>  use lib '/usr/local/share/departments/r_and_d/shared_files/mp3s/';
>
>Then the 'use' for that module will work:
>
>  use Foo::Bar;
>
>You could even install the module into your home directory, as long as
>permissions were in order for your college's to see the module...
>or they could install a copy in their home directory and do something in
>the program using the module like:
>
>  BEGIN {
>      my($name,$passwd,$uid,$gid, $quota,$comment,$gcos,$dir,$shell,$expire) = getpwuid $<;
>      push @INC, $dir . '/perl_modules';
>  }
>
>But that's fugly =P
>
>-scott
>  
>
>
>On  0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
>  
>
>>	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
>>>      
>>>
>>_______________________________________________
>>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.





More information about the Phoenix-pm mailing list