Front page | perl.documentation |
Postings from December 2010
Re: Current Issues with perlipc.pod - should they be fixed?
Thread Previous
|
Thread Next
From:
Ruud H.G. van Tol
Date:
December 3, 2010 12:11
Subject:
Re: Current Issues with perlipc.pod - should they be fixed?
Message ID:
4CF94EF9.7070605@isolution.nl
On 2010-12-03 13:49, Shlomi Fish wrote:
> after I posted my series of patches to perlipc.pod , I saw that tchrist posted
> his version, which got accepted immediately. As a downside to that, I'll have
> to restart my work. However, I noticed that perlipc.pod still has many
> perceived issues. Here is a list of things I noticed:
>
> * «defined($Config{sig_name}) || die "No sigs?"; »
>
> Shouldn't it be using "or" instead of "||" or maybe an if?
>
> *
> <<<
> foreach $name (split(" ", $Config{sig_name})) {
> $signo{$name} = $i;
> $signame[$i] = $name;
> $i++;
> }
>>>>
>
> "foreach my $name" (Gotta practice what we preach). Furthermore, someone said
> we should recommend using a CPAN module for that instead.
>
> * unless (kill(0 => $pid) || $!{EPERM}) {
> warn "$pid looks dead";
> }
>
> unless and and ||? That's a bit confusing.
>
> *
>
> <<<
> my $ALARM_EXCEPTION = "alarm clock restart";
> eval {
> local $SIG{ALRM} = sub { die $ALARM_EXCEPTION };
> alarm 10;
> flock(FH, 2) # blocking write lock
> || die "cannot flock: $!";
> alarm 0;
> };
> if ($@&& $@ !~ quotemeta($ALARM_EXCEPTION)) { die }
>>>>
>
> Non-lexical filehandle.
>
IMO, direct testing of $@ should also be discouraged.
It should test the (enforced) truth of the return value of the eval.
> *
>
> <<<
> # system return val is backwards, so&& not ||
> #
> $ENV{PATH} .= ":/etc:/usr/etc";
> if ( system("mknod", $path, "p")
> && system("mkfifo", $path) )
> {
> die "mk{nod,fifo} $path failed";
> }
>>>>
>
> We probably want local $ENV{PATH} here, and can't we expect the mkfifo system
> call to work globally already?
>
> *
> <<<
> chdir(); # go home
> my $FIFO = ".signature";
>
> while (1) {
> unless (-p $FIFO) {
> unlink $FIFO; # discard any failure, will catch later
> require POSIX; # delayed loading of heavy module
> POSIX::mkfifo($FIFO, 0700)
> || die "can't mkfifo $FIFO: $!";
> }
>
> # next line blocks till there's a reader
> open (FIFO, "> $FIFO") || die "can't open $FIFO: $!";
> print FIFO "John Smith (smith\@host.org)\n", `fortune -s`;
> close(FIFO) || die "can't close $FIFO: $!";
> sleep 2; # to avoid dup signals
> }
>>>>
>
> Bareword filehandle, and 2-args open and || instead of or. I won't mention
> bareword filehandles again, but the exist in many other places.
>
> *
> <<<
> use FileHandle;
> use IPC::Open2;
> $pid = open2(*Reader, *Writer, "cat -un");
> print Writer "stuff\n";
> $got =<Reader>;
>>>>
>
> We need to make it use strict friendly.
>
> *
> <<<
> #!/usr/bin/perl -w
>>>>
>
> use warnings instead of "-w".
>
> *
>
> <<<
> my ($remote, $port, $iaddr, $paddr, $proto, $line);
>
> $remote = shift || "localhost";
> $port = shift || 2345; # random port
> if ($port =~ /\D/) { $port = getservbyname($port, "tcp") }
> die "No port" unless $port;
> $iaddr = inet_aton($remote) || die "no host: $remote";
>>>>
> we should declare the variables at first assignment instead of all in one
> place.
>
> *
> Shouldn't the example use IO::Socket and friends?
>
> *
> <<<
> And here's a multithreaded version. It's multithreaded in that
> like most typical servers, it spawns (fork()s) a slave server to
> handle the client request so that the master server can quickly
> go back to service a new client.
>>>>
>
> The term "multithreaded" is misleading it. It is multi-processed - not
> multithreaded, because it does not use threads.
>
> *
> <<<
> Section 5 of CPAN's F<modules> file is devoted to "Networking, Device
> Control (modems), and Interprocess Communication", and contains numerous
> unbundled modules numerous networking modules, Chat and Expect operations,
> CGI programming, DCE, FTP, IPC, NNTP, Proxy, Ptty, RPC, SNMP, SMTP, Telnet,
> Threads, and ToolTalk--to name just a few.
>>>>
>
> We should no longer mention that modules file.
>
> Should I send patches to correct all these issues (because the Perl
> documentation should represent the best practices)? And I hope that this time
> all my work will not be for naught again.
I agree to most, if not all of your 'corrrections'.
--
Ruud
Thread Previous
|
Thread Next