[32816] in Perl-Users-Digest
Perl-Users Digest, Issue: 4081 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Nov 21 16:09:52 2013
Date: Thu, 21 Nov 2013 13:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 21 Nov 2013 Volume: 11 Number: 4081
Today's topics:
goto <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: goto <rweikusat@mobileactivedefense.com>
Re: goto <bill@todbe.com>
Re: goto <derykus@gmail.com>
Re: goto <gravitalsun@foo.com>
Re: goto <derykus@gmail.com>
Re: goto <rweikusat@mobileactivedefense.com>
Re: goto <Huge@nowhere.much.invalid>
Re: goto <hjp-usenet3@hjp.at>
Re: Program Translation - Nov. 14, 2013 (Tim McDaniel)
Re: Program Translation - Nov. 14, 2013 <cwilbur@chromatico.net>
Re: Several Topics - Nov. 19, 2013 <gamo@telecable.es>
Re: Several Topics - Nov. 19, 2013 <gah@ugcs.caltech.edu>
Re: Several Topics - Nov. 19, 2013 <gravitalsun@foo.com>
Re: Several Topics - Nov. 19, 2013 <cwilbur@chromatico.net>
Re: Several Topics - Nov. 19, 2013 <jurgenex@hotmail.com>
Re: Several Topics - Nov. 19, 2013 <gamo@telecable.es>
Writing a daemon to start/stop at boot and shutdown. <justin.1303@purestblue.com>
Re: Writing a daemon to start/stop at boot and shutdown <dave@invalid.invalid>
Re: Writing a daemon to start/stop at boot and shutdown <thepoet_nospam@arcor.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 20 Nov 2013 16:36:58 +0200
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: goto
Message-Id: <l6ihd2$hep$1@news.ntua.gr>
# why it complaints ?
use strict;
use warnings;
goto Initialize_variables;
main_loop:
print $MODE;
goto end;
Initialize_variables:
my $MODE = "hello world\n";
goto main_loop;
end:
------------------------------
Date: Wed, 20 Nov 2013 14:53:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: goto
Message-Id: <87iovn6s6m.fsf@sable.mobileactivedefense.com>
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
writes:
> # why it complaints ?
> use strict;
> use warnings;
> goto Initialize_variables;
> main_loop:
> print $MODE;
> goto end;
> Initialize_variables:
> my $MODE = "hello world\n";
> goto main_loop;
> end:
-----
use Devel::Peek;
goto Initialize_variables;
main_loop:
print $MODE;
Dump($MODE);
goto end;
Initialize_variables:
my $MODE = "hello world\n";
Dump($MODE);
goto main_loop;
end:
-----
The compiler doesn't execute goto-statements, hence, by the time the
print $MODE;
is compiled, it refers to an undeclared package variable named $MODE.
------------------------------
Date: Wed, 20 Nov 2013 15:04:40 -0800
From: "$Bill" <bill@todbe.com>
Subject: Re: goto
Message-Id: <l6jf66$htc$1@dont-email.me>
On 11/20/2013 06:53, Rainer Weikusat wrote:
> George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
> writes:
>> # why it complaints ?
>> use strict;
>> use warnings;
>> goto Initialize_variables;
>> main_loop:
>> print $MODE;
>> goto end;
>> Initialize_variables:
>> my $MODE = "hello world\n";
>> goto main_loop;
>> end:
>
> -----
> use Devel::Peek;
>
> goto Initialize_variables;
> main_loop:
> print $MODE;
> Dump($MODE);
> goto end;
> Initialize_variables:
> my $MODE = "hello world\n";
> Dump($MODE);
> goto main_loop;
> end:
> -----
>
> The compiler doesn't execute goto-statements, hence, by the time the
>
> print $MODE;
>
> is compiled, it refers to an undeclared package variable named $MODE.
In other words, 'declare' $MODE prior to it's first use in file:
use strict;
use warnings;
my $MODE;
goto Initialize_variables;
main_loop:
print $MODE;
goto end;
Initialize_variables:
$MODE = "hello world\n";
goto main_loop;
end:
__END__
------------------------------
Date: Wed, 20 Nov 2013 15:14:08 -0800
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: goto
Message-Id: <l6jfo7$vti$1@speranza.aioe.org>
On 11/20/2013 6:36 AM, George Mpouras wrote:
> # why it complaints ?
> use strict;
> use warnings;
> goto Initialize_variables;
> main_loop:
> print $MODE;
> goto end;
> Initialize_variables:
> my $MODE = "hello world\n";
> goto main_loop;
> end:
You could globalize $MODE as a workkaround:
use vars qw/$MODE/;
...
#my $MODE = "hello,world";
$MODE = "hello world";
or, just change the lexical scope:
my $MODE;
goto Initialize_variables;
...
Initialize_variables:
#my $MODE = "hello,world";
$MODE = "hello world\n";
--
Charles DeRykus
------------------------------
Date: Thu, 21 Nov 2013 11:33:22 +0200
From: George Mpouras <gravitalsun@foo.com>
Subject: Re: goto
Message-Id: <l6kjvq$1nva$1@news.ntua.gr>
> You could globalize $MODE as a workkaround:
>
of course there are workarounds; I just found it strange because there
is no { } closure to localize the var.
Rainer said the goto is not compiled, ok, this explains the behavior,
but it is also strange
------------------------------
Date: Thu, 21 Nov 2013 05:47:45 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: goto
Message-Id: <bf828ed0-77d2-4138-9a39-b4ac4aee13b1@googlegroups.com>
On Thursday, November 21, 2013 1:33:22 AM UTC-8, George Mpouras wrote:
> > You could globalize $MODE as a workkarounds
> of course there are workarounds; I just found it strange because there
> is no { } closure to localize the var.
> Rainer said the goto is not compiled, ok, this explains the behavior,
But, the error is due to 'strict'. I'm not sure how closure
and localizing create any confusion.
> but it is also strange
It'd be even stranger if goto had some kind of compile-time
behavior that could alter the semantics of lexical scope.
--
Charles DeRykus
------------------------------
Date: Thu, 21 Nov 2013 14:13:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: goto
Message-Id: <87eh69zvv2.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@foo.com> writes:
>> You could globalize $MODE as a workkaround:
>>
>
> of course there are workarounds; I just found it strange because there
> is no { } closure to localize the var.
> Rainer said the goto is not compiled, ok, this explains the behavior,
> but it is also strange
The compiler doesn't run the program, hence, it doesn't follow it's
runtime control flow. It basically processes an input file sequentially
from the first line to the last line, similar to a person walking
backwards on a straight path: It can see everything it already
encountered so far but can't look at anything it might encounter during
the course of the next five steps. Another way to describe this would be
that the location on this path were the person/ compiler presently
stands represents 'the present', the set of previously occupied
locations would be 'the past' and anything behind (the person/ compiler
is still looking backwards) was 'the future' and nothing is really known
about that (although an intelligent being could come up with a set of
more or less likely conjectures about it). 'goto' can be used to
introduce arbitrary twists and turns in this otherwise sequential flow of
time (that's what's behind the ominous murmur of
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
) but only when it is actually executed.
Assuming the following Perl code:
-------
goto omy;
ohyou:
print $MODE, "\n";
exit 0;
ohmy:
$MODE = 5;
goto ohyou;
-------
The 'Perl dissassembler' can be used to display the 'op tree' generated
from this. It is (perl -MO=Concise ...):
i <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 a.pl:1) v:{ ->3
3 <"> goto("omy") v ->4
4 <;> nextstate(ohyou: main 1 a.pl:3) v:{ ->5
8 <@> print vK ->9
5 <0> pushmark s ->6
- <1> ex-rv2sv sK/1 ->7
6 <#> gvsv[*MODE] s ->7
7 <$> const[PV "\n"] s ->8
9 <;> nextstate(main 1 a.pl:5) v:{ ->a
b <1> exit vK/1 ->c
a <$> const[IV 0] s ->b
c <;> nextstate(ohmy: main 1 a.pl:7) v:{ ->d
f <2> sassign vKS/2 ->g
d <$> const[IV 5] s ->e
- <1> ex-rv2sv sKRM*/1 ->f
e <#> gvsv[*MODE] s ->f
g <;> nextstate(main 1 a.pl:9) v:{ ->h
h <"> goto("ohyou") v ->i
The 'gotos' appear in that as 'operator with a string argument', that's
what the compiler makes of them. This code can't really be executed
because of the intentional spelling error in the first line ('omy'
versus 'ohmy') but op-tree generation step is oblivious of (to?) that.
This is also documented behaviour, cf
The declared variable is not introduced (is not visible) until
after the current statement. Thus,
my $x = $x;
can be used to initialize a new $x with the value of the old $x
(perldoc perlsub)
------------------------------
Date: 21 Nov 2013 15:30:51 GMT
From: Huge <Huge@nowhere.much.invalid>
Subject: Re: goto
Message-Id: <bf6n9bFiqhrU3@mid.individual.net>
On 2013-11-21, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> George Mpouras <gravitalsun@foo.com> writes:
>>> You could globalize $MODE as a workkaround:
>>>
>>
>> of course there are workarounds; I just found it strange because there
>> is no { } closure to localize the var.
>> Rainer said the goto is not compiled, ok, this explains the behavior,
>> but it is also strange
>
> The compiler doesn't run the program, hence, it doesn't follow it's
> runtime control flow. It basically processes an input file sequentially
> from the first line to the last line, similar to a person walking
> backwards on a straight path: It can see everything it already
> encountered so far but can't look at anything it might encounter during
> the course of the next five steps.
Hence multi-pass compilers ...
--
Today is Setting Orange, the 33rd day of The Aftermath in the YOLD 3179
Human being; a spacesuit for a fish
------------------------------
Date: Thu, 21 Nov 2013 19:38:39 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: goto
Message-Id: <slrnl8skpf.jqh.hjp-usenet3@hrunkner.hjp.at>
On 2013-11-21 09:33, George Mpouras <gravitalsun@foo.com> wrote:
>> You could globalize $MODE as a workkaround:
>>
>
> of course there are workarounds; I just found it strange because there
> is no { } closure to localize the var.
A lexical variable is visible from the point where it is declared until
the end of the enclosing block. Since there are no {} in your code the
"enclosing block is your whole file.
So in
1| use strict;
2| use warnings;
3| goto Initialize_variables;
4| main_loop:
5| print $MODE;
6| goto end;
7| Initialize_variables:
8| my $MODE = "hello world\n";
9| goto main_loop;
10| end:
the variable $MODE is visible from the end of line 8 to line 10.
If you had written something like
1| use strict;
2| say "$MODE not visible";
3| {
4| say "$MODE still not visible";
5| my $MODE = "foo";
6| say "$MODE visible here";
7| }
8| say "$MODE not visible again";
$MODE would be visible from the end of line 5 to line 7.
hp
PS: There is a reason why variables declared with my() are called
"lexical" variables.
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 20 Nov 2013 00:42:14 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <l6h0h6$c2j$1@reader1.panix.com>
In article <8761ro12un.fsf@new.chromatico.net>,
Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>>>>> "TMcD" == Tim McDaniel <tmcd@panix.com> writes:
>
> TMcD> So I think it's more plausible to have a priori suspicion of
> TMcD> claims here.
>
>Oh, I think it's entirely likely that the whole earthquake prediction
>project is Internet-amplified crackpottery of the least harmful and most
>entertaining sort.
"Least harmful"?
http://www.cnn.com/2012/10/23/world/europe/italy-quake-scientists-guilty/
"Earthquake experts worldwide expressed shock at the manslaughter
convictions of six Italian scientists who failed to predict the deadly
L'Aquila quake, ..."
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 20 Nov 2013 11:26:17 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <871u2b11li.fsf@new.chromatico.net>
>>>>> "TMcD" == Tim McDaniel <tmcd@panix.com> writes:
>> Oh, I think it's entirely likely that the whole earthquake
>> prediction project is Internet-amplified crackpottery of the
>> least harmful and most entertaining sort.
TMcD> "Least harmful"?
EDGs project, not the whole scientific endeavor. The scientists in the
article you cite (url below) were held responsible for their prediction
which turned out to be incorrect. Since there's a legal concept of
malpractice, I think it's reasonable to ask whether the scientists were
guilty of it; I think, based on my knowledge of geology, that they were
not, but the court did, and that's why there are appeals processes.
Also, consider the other forms of Internet-amplified crackpottery; do
you really think a legal error, likely to be overturned on appeal, is
*more* damaging than white supremacy?
Charlton
TMcD> http://www.cnn.com/2012/10/23/world/europe/italy-quake-scientists-guilty/
TMcD> "Earthquake experts worldwide expressed shock at the
TMcD> manslaughter convictions of six Italian scientists who failed
TMcD> to predict the deadly L'Aquila quake, ..."
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 20 Nov 2013 21:48:06 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6j763$2jq$1@speranza.aioe.org>
El 19/11/13 23:43, glen herrmannsfeldt escribió:
>
> And, importantly, the code runs fairly slow. Some years ago, I was
> working with simple PERL programs that could process data at 1 megabyte
> per minute. Rewriting in C, I got one megabyte per second. It is not too
> unusual to run 10 times slower, but 60 was rediculous.
>
> -- glen
>
Can you provide more information on the topic? Perl version, method to
read/write, etc.
Thanks
------------------------------
Date: Thu, 21 Nov 2013 01:55:57 +0000 (UTC)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6jp7d$iim$1@speranza.aioe.org>
In comp.lang.fortran gamo <gamo@telecable.es> wrote:
(snip, I wrote)
>> And, importantly, the code runs fairly slow. Some years ago, I was
>> working with simple PERL programs that could process data at 1 megabyte
>> per minute. Rewriting in C, I got one megabyte per second. It is not too
>> unusual to run 10 times slower, but 60 was rediculous.
> Can you provide more information on the topic? Perl version, method to
> read/write, etc.
Well, it was about 10 years ago and written by someone else.
The programs read characters from a file, did a little processing on
them, usually with some kind of look-up table, and then wrote them out.
One was to generate the reverse complement of DNA sequences, so read
in a string (possibly multiple lines, a few hundred characters long)
look up each in a table to find a different character, then write
the string out backwards. I believe it used the perl equivalent to C's
getchar() and putchar().
Input and output in fasta format, and a few thousand to a few
million sequences, so about 1MB to 1GB total.
-- glen
------------------------------
Date: Thu, 21 Nov 2013 14:36:13 +0200
From: George Mpouras <gravitalsun@foo.com>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6kuml$2l6q$1@news.ntua.gr>
>
> One was to generate the reverse complement of DNA sequences, so read
> in a string (possibly multiple lines, a few hundred characters long)
> look up each in a table to find a different character, then write
> the string out backwards. I believe it used the perl equivalent to C's
> getchar() and putchar().
>
> Input and output in fasta format, and a few thousand to a few
> million sequences, so about 1MB to 1GB total.
>
> -- glen
>
You have to provide the old code and some sample data if you want to
have an answer
------------------------------
Date: Thu, 21 Nov 2013 14:35:37 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <87siupzgxi.fsf@new.chromatico.net>
>>>>> "gh" == glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
gh> The programs read characters from a file, did a little
gh> processing on them, usually with some kind of look-up table, and
gh> then wrote them out.
gh> One was to generate the reverse complement of DNA sequences, so
gh> read in a string (possibly multiple lines, a few hundred
gh> characters long) look up each in a table to find a different
gh> character, then write the string out backwards. I believe it
gh> used the perl equivalent to C's getchar() and putchar().
To be honest, this sounds like someone writing idiomatic C in Perl. I'd
expect competently written Perl to take at best ten times longer and
probably more like 20 times longer than competently written C for a task
like that, but it takes poor programming as well as language overhead to
produce results like that.
I implemented three subroutines that do what you describe - produce the
reverse complement of a DNA sequence (alien DNA, that has ABCD codons,
for simplicity). The first, "naive," expresses the logic clearly, but
has a lot of intentional inefficiencies of the sort I've seen smart but
inexperienced programmers make. The second, "reasonable," is the same
code as "naive" but with the obvious inefficiencies removed. The third,
"efficient," uses the most efficient and idiomatic Perl to solve the
problem. The actual code is below; the results are thus (formatting
adjusted):
Benchmark: timing 100000 iterations of idiomatic, naive, reasonable...
idiomatic: 2 wallclock secs ( 1.90 usr + 0.00 sys = 1.90 CPU)
@ 52631.58/s (n=100000)
naive: 2982 wallclock secs (1310.83 usr + 1.04 sys = 1311.87 CPU)
@ 76.23/s (n=100000)
reasonable: 1105 wallclock secs (1102.75 usr + 1.17 sys = 1103.92 CPU)
@ 90.59/s (n=100000)
Rate naive reasonable idiomatic
naive 76.2/s -- -16% -100%
reasonable 90.6/s 19% -- -100%
idiomatic 52632/s 68946% 58001% --
So we're looking at the idiomatic Perl version being 580 times faster
than the reasonable Perl version. But the idiomatic Perl version isn't
likely to be obvious to anyone who isn't deeply steeped in Perl and Unix
knowledge.
Charlton
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw/timethese cmpthese/;
our %lookup = ( A => 'D', B => 'C', C => 'B', D => 'A' );
my @codons = qw/A B C D/;
my @samples;
my $string_length = 10000;
my $sample_count = 10000;
for (1..$sample_count) {
my $str = '';
for (1..$string_length) {
$str .= $codons[rand() * 4];
}
push @samples, $str;
}
my $timing = timethese( 100000, {
naive => sub { naive ($samples[rand() * $sample_count]); },
reasonable => sub { reasonable ($samples[rand() * $sample_count]); },
idiomatic => sub { idiomatic ($samples[rand() * $sample_count]);}
});
cmpthese($timing);
sub naive {
my $in = shift;
my @codons = split '', $in;
my @out_codons;
for (my $i = 0; $i < scalar @codons; $i++) {
if ($codons[$i] eq 'A') {
$out_codons[$i] = 'D';
}
if ($codons[$i] eq 'B') {
$out_codons[$i] = 'C';
}
if ($codons[$i] eq 'C') {
$out_codons[$i] = 'B';
}
if ($codons[$i] eq 'D') {
$out_codons[$i] = 'A';
}
}
my @reversed_out_codons = reverse @out_codons;
my $output = join '', @reversed_out_codons;
return $output;
}
sub reasonable {
my $in = shift;
my @codons = split '', $in;
my @out_codons = map { $lookup{$_} } @codons;
my $output = join '', reverse @out_codons;
return $output;
}
sub idiomatic {
my $in = shift;
$in =~ y/ABCD/DCBA/;
$in = reverse $in;
return $in;
}
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 21 Nov 2013 12:19:17 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <oeqs89502circ3h8gp6njp4juttv35u9id@4ax.com>
Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>>>>> "gh" == glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
> gh> The programs read characters from a file, did a little
> gh> processing on them, usually with some kind of look-up table, and
> gh> then wrote them out.
>
> gh> One was to generate the reverse complement of DNA sequences, so
> gh> read in a string (possibly multiple lines, a few hundred
> gh> characters long) look up each in a table to find a different
> gh> character, then write the string out backwards. I believe it
> gh> used the perl equivalent to C's getchar() and putchar().
>
>To be honest, this sounds like someone writing idiomatic C in Perl. I'd
>expect competently written Perl to take at best ten times longer and
>probably more like 20 times longer than competently written C for a task
>like that, but it takes poor programming as well as language overhead to
>produce results like that.
ACK
>I implemented three subroutines that do what you describe - produce the
>reverse complement of a DNA sequence (alien DNA, that has ABCD codons,
>for simplicity). [...]
My feeling is that most of this reported slow performance may come from
reading and writing individual characters: "it used the perl equivalent
to C's getchar() and putchar().".
If I'm not mistaken then doing so involves large overhead while reading
and writing larger blocks (several kB) is orders of magnitude faster in
Perl.
jue
------------------------------
Date: Thu, 21 Nov 2013 21:39:11 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Several Topics - Nov. 19, 2013
Message-Id: <l6lr1c$pao$1@speranza.aioe.org>
El 21/11/13 21:19, Jürgen Exner escribió:
...
> If I'm not mistaken then doing so involves large overhead while reading
> and writing larger blocks (several kB) is orders of magnitude faster in
> Perl.
>
> jue
What do you recomend to read a large file (i.e. 1 GB)?
a) sysread() with a length of, say 8192
b) use File::Slurp
Thanks
------------------------------
Date: Wed, 20 Nov 2013 15:44:54 +0000
From: Justin C <justin.1303@purestblue.com>
Subject: Writing a daemon to start/stop at boot and shutdown.
Message-Id: <m02vla-8oe.ln1@zem.masonsmusic.co.uk>
I've yet to write the file for /etc/init.d to start and stop my
program, but I don't think I should really go that far before I can
make my program detach itself and be able to stop when called with
'/usr/local/bin/progname stop'.
I've been reading the docs of Daemon::Control, Daemon::Generic and
Proc::Daemon, but I can't get my program to detach - the problem
appears that it never returns from one of the subs. Here's what
doesn't return:
start_program();
sub start_program {
my $server = RPC::Serialized::Server::NetServer->new({
net_server => {port => $port},
rpc_serialized => {
handlers => {
echo => 'My::Echo',
address_lookup => 'My::AddressLookup',
}
},
});
$server->run;
}
The program works in that there is a server listening, and responding
to requests from other servers on the network.
All suggestions gratefully received.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 20 Nov 2013 18:00:02 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Writing a daemon to start/stop at boot and shutdown.
Message-Id: <fV45K0OBJxbE-pn2-mxpmFgoSIzZt@paddington.bear.den>
On Wed, 20 Nov 2013 15:44:54 UTC, Justin C
<justin.1303@purestblue.com> wrote:
> I've yet to write the file for /etc/init.d to start and stop my
> program, but I don't think I should really go that far before I can
> make my program detach itself and be able to stop when called with
> '/usr/local/bin/progname stop'.
>
Well the classic C method is to fork yourself having reassigned
STDin/out/err to disconnect from the starting terminal. Why bother
when the start script can just & the program?
--
Regards
Dave Saville
------------------------------
Date: Wed, 20 Nov 2013 19:19:36 +0100
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Writing a daemon to start/stop at boot and shutdown.
Message-Id: <528cfd38$0$6633$9b4e6d93@newsspool2.arcor-online.net>
Am 20.11.2013 16:44, schrieb Justin C:
> I've yet to write the file for /etc/init.d to start and stop my
> program, but I don't think I should really go that far before I can
> make my program detach itself and be able to stop when called with
> '/usr/local/bin/progname stop'.
>
> I've been reading the docs of Daemon::Control, Daemon::Generic and
> Proc::Daemon, but I can't get my program to detach - the problem
> appears that it never returns from one of the subs.
It's documented in RPC::Serializd::Server::NetServer, section
"Things you might want to configure", where points (albeit in
slightly roundabout way) to the "background" option of Net::Server.
So somthing along the lines of this should work (untested):
...
my $server = RPC::Serialized::Server::NetServer->new({
net_server => {
port => $port,
background = 1
},
...
HTH
-Chris
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4081
***************************************
