[32653] in Perl-Users-Digest
Perl-Users Digest, Issue: 3929 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 20 14:09:30 2013
Date: Sat, 20 Apr 2013 11:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 20 Apr 2013 Volume: 11 Number: 3929
Today's topics:
has the wrong ${@$row}[3] instead of $$row[3] for the a meshulum@gmail.com
Re: has the wrong ${@$row}[3] instead of $$row[3] for t <derykus@gmail.com>
Re: has the wrong ${@$row}[3] instead of $$row[3] for t <ben@morrow.me.uk>
mojolicious quantum step forward in perl web framework? <visphatesjava@gmail.com>
Re: mojolicious quantum step forward in perl web framew <rweikusat@mssgmbh.com>
Re: More idiomatic <derykus@gmail.com>
Re: More idiomatic <derykus@gmail.com>
Re: More idiomatic <ben@morrow.me.uk>
Re: More idiomatic <ben@morrow.me.uk>
Re: More idiomatic <derykus@gmail.com>
starman fastest perl web server? <visphatesjava@gmail.com>
Re: This looks like a Perl bug <ben@morrow.me.uk>
Re: This looks like a Perl bug <rvtol+usenet@xs4all.nl>
Re: This looks like a Perl bug <ben@morrow.me.uk>
Re: This looks like a Perl bug <bugbear@trim_papermule.co.uk_trim>
Re: This looks like a Perl bug <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <ben@morrow.me.uk>
timeout a print to stdout? <dave@invalid.invalid>
Re: timeout a print to stdout? <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 19 Apr 2013 16:03:00 -0700 (PDT)
From: meshulum@gmail.com
Subject: has the wrong ${@$row}[3] instead of $$row[3] for the array reference $row worsened bet 5.8.8 and 5.14.2
Message-Id: <ef97cac2-1b59-4c5d-98cd-6c2698bbc18e@googlegroups.com>
Dear Gurus,
I had some legacy CGI code (running for years without rereview)
written when I first learned perl
which worked on many old machines from redhat 7.2
even through on an old debian 4 machine circa 2008 which
was running perl 5.8.
Now it has
stopped working on a new debian sid machine running
perl 5.14.2
The crucial error I discovered
was that i was working with an
array reference $row
which was returned by fetchall_arrayref
and I had multiple lines that looked like
${@$row}[3]
(I know, I was just a beginner)
which stopped working.
Of course now it works again
when I now use
$$row[3].
How is it that my error was tolerated on perl 5.8 and 5.6
but now is no longer tolerated.
Any references (:)) where I can read about this change?
Meshulum
---
------------------------------
Date: Fri, 19 Apr 2013 18:49:14 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: has the wrong ${@$row}[3] instead of $$row[3] for the array reference $row worsened bet 5.8.8 and 5.14.2
Message-Id: <kkss6u$d9v$1@speranza.aioe.org>
On 4/19/2013 4:03 PM, meshulum@gmail.com wrote:
>
> I had some legacy CGI code (running for years without rereview)
> written when I first learned perl
> which worked on many old machines from redhat 7.2
> even through on an old debian 4 machine circa 2008 which
> was running perl 5.8.
>
> Now it has
> stopped working on a new debian sid machine running
> perl 5.14.2
>
> The crucial error I discovered
> was that i was working with an
> array reference $row
> which was returned by fetchall_arrayref
>
> and I had multiple lines that looked like
>
> ${@$row}[3]
>
> (I know, I was just a beginner)
>
> which stopped working.
>
> Of course now it works again
>
> when I now use
>
> $$row[3].
>
> How is it that my error was tolerated on perl 5.8 and 5.6
> but now is no longer tolerated.
>
> Any references (:)) where I can read about this change?
>
I'm just guessing but I wonder if this might be relevant from
perl5100delta:
The av_*() functions, used to manipulate arrays, no longer
accept null AV* parameters
(See perlapi for discussion of the av_*() functions)
Since an AV* ref would be expected in ${...}[3], this would not
now work unless you created an array ref:
${\@$row}[3]
But $$row[3] works because $row is a valid array ref.
So, continuing the speculation, in earlier versions, the av_*
functions may have allowed a list in lieu of an array ref.
--
Charles DeRykus
------------------------------
Date: Sat, 20 Apr 2013 03:43:02 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: has the wrong ${@$row}[3] instead of $$row[3] for the array reference $row worsened bet 5.8.8 and 5.14.2
Message-Id: <mub94a-31a.ln1@anubis.morrow.me.uk>
Quoth meshulum@gmail.com:
> Dear Gurus,
>
> I had some legacy CGI code (running for years without rereview)
> written when I first learned perl
> which worked on many old machines from redhat 7.2
> even through on an old debian 4 machine circa 2008 which
> was running perl 5.8.
>
> Now it has
> stopped working on a new debian sid machine running
> perl 5.14.2
>
> The crucial error I discovered
> was that i was working with an
> array reference $row
> which was returned by fetchall_arrayref
>
> and I had multiple lines that looked like
>
> ${@$row}[3]
>
> (I know, I was just a beginner)
>
> which stopped working.
>
> Of course now it works again
>
> when I now use
>
> $$row[3].
>
> How is it that my error was tolerated on perl 5.8 and 5.6
> but now is no longer tolerated.
Hmm, odd. This appears to have stopped working in 5.10.0, but there
isn't any reference to it in perl5100delta. It was always invalid
syntax, of course, so the fact 5.6 and 5.8 allowed it was a bug in those
perls.
This is obviously related to the 'Using an array as a reference is
deprecated' warning that was introduced in 5.8, and in fact if you
recast the expression as
@{$row}->[3]
it still works in current perls, with a warning. I don't really
understand why the ${}[] syntax behaves differently.
Ben
------------------------------
Date: Fri, 19 Apr 2013 23:04:46 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: mojolicious quantum step forward in perl web framework?S
Message-Id: <232bcd7d-b3bb-467d-b067-5ef48a7a154a@googlegroups.com>
or is poet or dancer best?
------------------------------
Date: Sat, 20 Apr 2013 18:50:32 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: mojolicious quantum step forward in perl web framework?S
Message-Id: <87k3nxqefr.fsf@sapphire.mobileactivedefense.com>
johannes falcone <visphatesjava@gmail.com> writes:
> or is poet or dancer best?
People usually implement 'frameworks' because they remember having a
seriously hard time solving some set of more or less related problems,
IOW, they are written by people who have no real idea how to solve
these problems. That's a bit like the universal dinner invented by
someone who couldn't cook aka McDonalds: A good choice if you want
something cheap which is somewhat warm and not grossly dubious
quickly.
In case of 'Mojolicious', not grossly dubious needs to be taken with
a grain of salt: A piece of information which whizzed by here some time
ago is that this frameworks periodically re-execs the process it is
running in (According to Ben Morrow. I have no idea if it
actually does that) and the 'obvious' suspicion why it does this
would be that someone's trying to sweep a set of memory leaks under
the carpet (that's a conjecture which may be wrong).
------------------------------
Date: Thu, 18 Apr 2013 13:25:43 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <kkpks6$kc5$1@speranza.aioe.org>
On 4/18/2013 10:54 AM, David Harmon wrote:
> On Wed, 17 Apr 2013 23:02:51 -0700 (PDT) in comp.lang.perl.misc,
> "C.DeRykus" <derykus@gmail.com> wrote,
>> One possibility to avoid an artificial concatenation
>> character and then needing to break it down later:
>>
>> my $key = "$fromline$useragent$hascont";
>> $statstab{$key} = [
>> (${$statstab{$key}}[0] //= $fromline),
>> (${$statstab{$key}}[1] //= $useragent),
>> (${$statstab{$key}}[2] //= $hascont),
>
> Sorry to disagree, but I much prefer Ben's hash with mnemonic keys
> over this array with numeric indexes that I must track the meaning
> of by additional effort.
>
Ok. But this ugly first attempt morphed into a more idiomatic,
elegant form thanks to some helpful follow-on suggestions:
use constant COUNT => 3;
...
$statstab{$key} ||= [$fromline, $useragent, $hascont];
++$statstab{$key}[COUNT];
...
for (sort keys %statstab) {
($fromline,$useragent,$hascont) = @{$statstab{$_}}[0.COUNT-1]
...
Now you have a single mnemonic and you don't have to worry about
that pesky, ugly concatenation/de-concatenation. Nor do you have
to sweat pickinng a safe concatenator string. (IMO, the
multi-dimensional array emulation is ugly, old-school stuff).
Short, elegant, arguably safer and more idiomatic... at least again
IMO.
--
Charles DeRykus
------------------------------
Date: Thu, 18 Apr 2013 13:55:50 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <kkpmkl$pcm$1@speranza.aioe.org>
On 4/18/2013 10:28 AM, Keith Thompson wrote:
> Jürgen Exner <jurgenex@hotmail.com> writes:
> [...]
>> As if full-quotes aren't bad enough is there any sane reason why you are
>> doubling your quotes by inserting an additional empty line after each
>> and every quoted line? That is nuts!
>> And yet worse: attribute those added lines to the previous poster?
>>
>> Would you stop doing that ASAP, please.
>
> Google Groups does that automatically. Yes, it's stupid.
>
Evidently, a new GG feature.
But I'm atoning for my sins by reverting to Thunderbird.
--
Charles DeRykus
------------------------------
Date: Fri, 19 Apr 2013 00:16:09 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More idiomatic
Message-Id: <peb64a-f3k2.ln1@anubis.morrow.me.uk>
Quoth "C.DeRykus" <derykus@gmail.com>:
> On Wednesday, April 17, 2013 7:54:31 AM UTC-7, David Harmon wrote:
> > On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
> >
> > Morrow <ben@morrow.me.uk> wrote,
> >
> > >I think the strategy I might go for here would be to concatenate the
> >
> > >pieces to get a unique key, but not try to pull them out again
> >
> > >afterwards. Instead put the individual pieces in a structure,
> >
> >
> >
> > Yes, I think that is a good answer.
>
>
> One possibility to avoid an artificial concatenation
> character and then needing to break it down later:
>
>
> my $key = "$fromline$useragent$hascont";
You still want a separator character, to distinguish between the cases
($fromline, $useragent) = ("a", "bc")
($fromline, $useragent) = ("ab", "c")
> $statstab{$key} = [
> (${$statstab{$key}}[0] //= $fromline),
> (${$statstab{$key}}[1] //= $useragent),
> (${$statstab{$key}}[2] //= $hascont),
> do{${$statstab{$key}}[3] //= 0; ++${$statstab{$key}}[3]}
> ];
>
> ...
> for (sort keys %statstab) {
> ($fromline,$useragent,$hascont) = @{$statstab{$_}}[0.2]
This is otherwise no different in principle from my suggestion, except
for using an arrayref instead of a hashref. I consider a hashref with
named keys easier to understand, notwithstanding Rainer's usual
suggestion of an arrayref with constants for the indices.
What would be nice, actually, is some way of making Hash::Util's
restricted hashes a bit less unwieldy. The functionality I want is there
(a hash with a restricted set of keys, so that typos can be detected),
it's just so awkward to use practically noone bothers.
Ben
------------------------------
Date: Fri, 19 Apr 2013 00:19:16 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More idiomatic
Message-Id: <kkb64a-f3k2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> David Harmon <source@netcom.com> writes:
> > On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
> > Morrow <ben@morrow.me.uk> wrote,
> >>I think the strategy I might go for here would be to concatenate the
> >>pieces to get a unique key, but not try to pull them out again
> >>afterwards. Instead put the individual pieces in a structure,
> >
> > Yes, I think that is a good answer.
>
> Perl also supports 'multidimensional hash keys'. An expression of the
> form
>
> $h{a,c,b}
>
> is equivalent to using a hash key which is created automtically by
> joining the components with the current value of $; as separator
> (default is \034), => perlvar(1)
This functionality is now sufficiently obscure (not to mention rather
easy to confuse with a hash slice) that I would consider an
explicit concatenation to be much clearer. Also, the fact that the OP's
code was effectively equivalent to the perl-4-ish multidim hashes is
what made me suggest a proper perl-5 multidim hash in the first place...
Ben
------------------------------
Date: Thu, 18 Apr 2013 16:50:19 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: More idiomatic
Message-Id: <kkq0ru$jn3$1@speranza.aioe.org>
On 4/18/2013 1:25 PM, Charles DeRykus wrote:
> On 4/18/2013 10:54 AM, David Harmon wrote:
>> On Wed, 17 Apr 2013 23:02:51 -0700 (PDT) in comp.lang.perl.misc,
>> "C.DeRykus" <derykus@gmail.com> wrote,
>>> One possibility to avoid an artificial concatenation
>>> character and then needing to break it down later:
>>>
>>> my $key = "$fromline$useragent$hascont";
>>> $statstab{$key} = [
>>> (${$statstab{$key}}[0] //= $fromline),
>>> (${$statstab{$key}}[1] //= $useragent),
>>> (${$statstab{$key}}[2] //= $hascont),
>>
>> Sorry to disagree, but I much prefer Ben's hash with mnemonic keys
>> over this array with numeric indexes that I must track the meaning
>> of by additional effort.
>>
>
> Ok. But this ugly first attempt morphed into a more idiomatic,
> elegant form thanks to some helpful follow-on suggestions:
>
> use constant COUNT => 3;
> ...
> $statstab{$key} ||= [$fromline, $useragent, $hascont];
> ++$statstab{$key}[COUNT];
> ...
>
> for (sort keys %statstab) {
> ($fromline,$useragent,$hascont) = @{$statstab{$_}}[0.COUNT-1]
> ...
>
> Now you have a single mnemonic and you don't have to worry about
> that pesky, ugly concatenation/de-concatenation. Nor do you have
> to sweat pickinng a safe concatenator string. (IMO, the
> multi-dimensional array emulation is ugly, old-school stuff).
>
> Short, elegant, arguably safer and more idiomatic... at least again
> IMO.
Per suggestion, you could use a concatenation separator to completely
bullet-proof:
# my $key = "$fromline$useragent$hascont";
my $key = join($;,$fromline, $useragent, $hascont); # <-- safer
--
Charles DeRykus
------------------------------
Date: Fri, 19 Apr 2013 15:25:35 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: starman fastest perl web server?
Message-Id: <43a9eca6-3ca2-40fd-8d0c-06ad4c173519@googlegroups.com>
wondering?
------------------------------
Date: Fri, 19 Apr 2013 00:26:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: This looks like a Perl bug
Message-Id: <f2c64a-f3k2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> "Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> > On 2013-04-18 17:33, George Mpouras wrote:
> >> # it should print string, string but it prints string number
> >> # there is no explanation for this behavior
> >>
> >> weird('2') for 1..2;
> >>
> >> sub weird {
> >> my $num = $_[0] eq '' ? 0 : $_[0] ^ $_[0] ? 0 : 1;
> >> my $col = $_[0] - 1; print $num ? "number\n" : "string\n"
> >> }
> >
> > Not a bug. The parameter '2' becomes numeric, because of the
> > operations.
>
> This is not quite true. Same effect with somewhat less code:
>
> ------------
> weird('2') for 1 .. 2;
>
> sub weird {
> my $num = $_[0] ^ $_[0] ? 0 : 1;
> my $col = $_[0] - 1;
> print $num ? "number\n" : "string\n"
> }
> ------------
>
> What happens here is that $_[0] ^ $_[0] returns a string whose value
> is a single 0-byte during the first call. This is not a 'logical false
> value', hence $num becomes 1. The $_[0] - 1 causes the scalar supplied
> as first argument to weird to become IOK, that is, it acquires an IV
> whose value is 2. The same scalar is used as argument to the second
> weird call. Consequently, $_[0] ^ $_[0] becomes an integer operation
> whose result is 0 which counts as false and $num becomes 1.
>
> If this is not considered a bug, this kind of 'silent' runtime
> modification of compile-time literals is at least very
> counter-intuitive.
IMHO the bug is not the fact the literal is type-extended (this is an
important perl efficiency feature) but that the bitwise ops behave
differently if their arguments are IOK. Perl has polymorphic values and
coercive operators, and every time someone breaks that rule it makes a
nasty mess. (A similar mistake was the root of 'the Unicode bug':
Perl-visible behaviour was changing depending on a Perl-invisible
dynamic type change.)
Ben
------------------------------
Date: Fri, 19 Apr 2013 08:43:13 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: This looks like a Perl bug
Message-Id: <5170e782$0$2266$e4fe514c@news2.news.xs4all.nl>
On 2013-04-18 20:11, George Mpouras wrote:
>>> But what are you trying to achieve?
>
> its a very big project , what you see here is a very small piece of code
> that expose the strange behaviour .
>
> we had a very big headache to find what was wrong and where .
Then what made you make the bad choice to depend on something internal?
This is in the "Doctor, it hurts when I press here." category.
It is basic to Perl that a value can have several natures at the same
time. And that these are cached. (Not nice for COW though.)
You now learned that you can use a copy of the parameter. Project saved?
Of course it is better to just get rid of the number/string thing
completely. How hard is that really?
--
Ruud
------------------------------
Date: Fri, 19 Apr 2013 09:03:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: This looks like a Perl bug
Message-Id: <laa74a-68u2.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> On 2013-04-18 20:11, George Mpouras wrote:
>
> >>> But what are you trying to achieve?
> >
> > its a very big project , what you see here is a very small piece of code
> > that expose the strange behaviour .
> >
> > we had a very big headache to find what was wrong and where .
>
> Then what made you make the bad choice to depend on something internal?
>
> This is in the "Doctor, it hurts when I press here." category.
> It is basic to Perl that a value can have several natures at the same
> time. And that these are cached. (Not nice for COW though.)
>
> You now learned that you can use a copy of the parameter. Project saved?
>
> Of course it is better to just get rid of the number/string thing
> completely. How hard is that really?
This is not quite fair. To give George his due, it isn't him that's
depending on the number/string distinction, it's the core bitwise ops.
IMHO this is a (probably unfixable at this point) core design bug, and
the moral is 'if you need to use the bitwise ops, be sure to explicitly
force the arguments to be string or numeric as desired'. int($x) or 0+$x
will force to numeric, "$x" will force to string (with no numeric bits
set).
For the record, the algorithm used is that if either of the arguments
has any of the 'numeric' bits set the op is numeric. Note that this
includes the private bits (which are set when a lossy conversion is
performed), so this
my $x = "1x";
say $x | "x";
$x + 1;
say $x | "x";
gives two different results, which is just bizarre.
Ben
------------------------------
Date: Fri, 19 Apr 2013 10:00:31 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: This looks like a Perl bug
Message-Id: <LYGdnWkCTIsymuzMnZ2dnUVZ7vmdnZ2d@brightview.co.uk>
Ben Morrow wrote:
> 'if you need to use the bitwise ops, be sure to explicitly
> force the arguments to be string or numeric as desired'.
Noted.
BugBear
------------------------------
Date: Fri, 19 Apr 2013 16:52:31 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87a9ou7c1s.fsf@sapphire.mobileactivedefense.com>
bugbear <bugbear@trim_papermule.co.uk_trim> writes:
> Ben Morrow wrote:
>> 'if you need to use the bitwise ops, be sure to explicitly
>> force the arguments to be string or numeric as desired'.
>
> Noted.
The 'core design error' mentioned here is part of a larger error named
'perl' which generally tries to make sense of the code which was
provided as input to it as hard as possible. The bit operators are
defined on both number and strings and which of the two operations is
supposed to be performed is determined by examining the arguments
provided to the operator in question: If one of the operands is a
number, the numeric operation is performed, otherwise, the 'bit
string' operation. This is also documented as such:
Bitstrings of any size may be manipulated by the bitwise
operators
[...]
If you are intending to manipulate bitstrings, be certain that
you're supplying bitstrings: If an operand is a number, that
will imply a numeric bitwise operation.
[perlop(1)]
In the given context, however, that's a tangential issue. The problem
George hit was that performing a side-effect free operation on an
implicitly created read-only scalar value can change the type of this
scalar from 'string' to 'number'.
------------------------------
Date: Sat, 20 Apr 2013 01:27:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: This looks like a Perl bug
Message-Id: <00494a-d56.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> bugbear <bugbear@trim_papermule.co.uk_trim> writes:
> > Ben Morrow wrote:
> >> 'if you need to use the bitwise ops, be sure to explicitly
> >> force the arguments to be string or numeric as desired'.
> >
> > Noted.
>
> The 'core design error' mentioned here is part of a larger error named
> 'perl' which generally tries to make sense of the code which was
> provided as input to it as hard as possible. The bit operators are
> defined on both number and strings and which of the two operations is
> supposed to be performed is determined by examining the arguments
> provided to the operator in question: If one of the operands is a
> number, the numeric operation is performed, otherwise, the 'bit
> string' operation.
No, the bitops' behaviour is *not* consistent with the rest of Perl.
Unlike some languages, the + operator (for instance) does not choose to
be 'addition' or 'concatenation' based on the dynamic types of its
arguments; instead, it always coerces its arguments to numbers and
performs addition. Similarly, Perl has separate == and eq equality
operators which coerce their arguments to number or string. The bitwise
ops should have been implemented the same way, with &, |, ^ and ~ always
coercing their arguments to numbers and (say) ba, bo, bx and bn always
coercing them to strings.
> This is also documented as such:
I realise it's documented. That doesn't stop it from being a bug.
> In the given context, however, that's a tangential issue. The problem
> George hit was that performing a side-effect free operation on an
> implicitly created read-only scalar value can change the type of this
> scalar from 'string' to 'number'.
This, on the other hand, is *not* a problem, and is something perl does
by design. Caching additional representations of a value should never
have any Perl-visible effect, as long as the core is careful to only set
the private flags when the conversion was lossy. (Note that the type of
the constant was not *changed*, it was added to: the string part was
still there, and the constant was still POK, it was just IOK as well.)
Ben
------------------------------
Date: Sat, 20 Apr 2013 14:07:33 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: timeout a print to stdout?
Message-Id: <fV45K0OBJxbE-pn2-8cbdFj2QHuhf@paddington.bear.den>
Due to lots of reasons I won't go into here I need a cgi-script to
push out video files. I knocked up a quick and dirty test that works
but if I kill the viewer the perl instance seems to hang around
forever. Although it is killable. It did occur to me that Apache might
kill it eventually when he sees the connection is not requesting
anymore data but it seems not.
So it the interests of being tidy I want to terminate if I have not
sent anything for X.
#!d:/usr/bin/perl5.16.0.exe
use strict;
use warnings;
print "Content-type: text/plain\n\n";
open my $STREAM, '<', "t:/tmp/Foo.rec" or die $!;
binmode $STREAM;
binmode STDOUT;
my $rc = 1;
while ( $rc )
{
$rc = read $STREAM, my $buffer, 4096;
die $! if undef $rc;
eval
{
local $SIG{ALRM} = sub{die "too long" };
alarm 60;
print $buffer;
alarm 0;
};
exit if $@ =~ m{^too long};
}
But it never terminates. Any ideas? I realise that both perl and
apache and the "system" are probably buffering away but whatever, I
would have though my script would wait in the print?
--
Regards
Dave Saville
------------------------------
Date: Sat, 20 Apr 2013 17:45:16 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: timeout a print to stdout?
Message-Id: <87zjwt2lsz.fsf@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
[...]
> So it the interests of being tidy I want to terminate if I have not
> sent anything for X.
>
> #!d:/usr/bin/perl5.16.0.exe
> use strict;
> use warnings;
> print "Content-type: text/plain\n\n";
> open my $STREAM, '<', "t:/tmp/Foo.rec" or die $!;
> binmode $STREAM;
> binmode STDOUT;
> my $rc = 1;
>
> while ( $rc )
> {
> $rc = read $STREAM, my $buffer, 4096;
> die $! if undef $rc;
This is nonsense: It cause the value of $rc to be changed to undef and
returns false aka 'an undefined value'. What you likely wanted is
something like this
die $! unless defined($rc)
or
$rc // die $!
Because of this, your script should really exit after the first
iteration ...
> eval
> {
> local $SIG{ALRM} = sub{die "too long" };
> alarm 60;
> print $buffer;
> alarm 0;
> };
> exit if $@ =~ m{^too long};
> }
>
> But it never terminates. Any ideas?
On UNIX(*), you could be a victim of so-called 'Deferred signals', see
perlipc(1) for details. I have no idea if this affecs 0.5OS ...
------------------------------
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 3929
***************************************
