[32654] in Perl-Users-Digest
Perl-Users Digest, Issue: 3930 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 23 03:09:30 2013
Date: Tue, 23 Apr 2013 00:09:08 -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 Tue, 23 Apr 2013 Volume: 11 Number: 3930
Today's topics:
Re: mojolicious quantum step forward in perl web framew <cwilbur@chromatico.net>
Re: This looks like a Perl bug <cwilbur@chromatico.net>
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 <rweikusat@mssgmbh.com>
Re: This looks like a Perl bug <cwilbur@chromatico.net>
Re: This looks like a Perl bug <xhoster@gmail.com>
Re: timeout a print to stdout? <ben@morrow.me.uk>
Re: timeout a print to stdout? <derykus@gmail.com>
Re: timeout a print to stdout? <rweikusat@mssgmbh.com>
Re: timeout a print to stdout? <dave@invalid.invalid>
Re: timeout a print to stdout? <rweikusat@mssgmbh.com>
Re: timeout a print to stdout? <derykus@gmail.com>
Re: 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: Sat, 20 Apr 2013 22:03:14 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: mojolicious quantum step forward in perl web framework?S
Message-Id: <87y5ccr671.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> johannes falcone <visphatesjava@gmail.com> writes:
>> or is poet or dancer best?
RW> People usually implement 'frameworks' because they remember
RW> having a seriously hard time solving some set of more or less
RW> related problems, IOW, they are written by people who have no
RW> real idea how to solve these problems.
At least our current crackpot can write coherently (if nonsensically) in
English when responding to trolls.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sat, 20 Apr 2013 18:17:48 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: This looks like a Perl bug
Message-Id: <8738uksv77.fsf@new.chromatico.net>
>>>>> "GM" == George Mpouras
>>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
>>>>> writes:
>>> But what are you trying to achieve?
GM> its a very big project , what you see here is a very small piece
GM> of code that expose the strange behaviour .
GM> we had a very big headache to find what was wrong and where .
The wrong thing is that you are trying to determine whether something is
a string or a number with foolish hackish approaches.
Read perlfaq4, s.v. "How do I determine whether a scalar is a
number/whole/integer/float?" and be enlightened.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 21 Apr 2013 04:54:28 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: This looks like a Perl bug
Message-Id: <kg4c4a-mqu.ln1@anubis.morrow.me.uk>
Quoth Charlton Wilbur <cwilbur@chromatico.net>:
> >>>>> "GM" == George Mpouras
> >>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
> >>>>> writes:
>
> >>> But what are you trying to achieve?
>
> GM> its a very big project , what you see here is a very small piece
> GM> of code that expose the strange behaviour .
>
> GM> we had a very big headache to find what was wrong and where .
>
> The wrong thing is that you are trying to determine whether something is
> a string or a number with foolish hackish approaches.
You're making the same mistake as Dr.Ruud. I don't believe George was
trying to determine whether a scalar was a string or a number, he was
being bitten by the fact the bitops change their behaviour based on
that.
Ben
------------------------------
Date: Sun, 21 Apr 2013 06:54:42 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: This looks like a Perl bug
Message-Id: <51737112$0$2225$e4fe514c@news2.news.xs4all.nl>
On 2013-04-21 05:54, Ben Morrow wrote:
> You're making the same mistake as Dr.Ruud.
No mistake here yet. Let George first explain why he was doing things as
smelly as he did.
--
Ruud
------------------------------
Date: Sun, 21 Apr 2013 13:55:48 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: This looks like a Perl bug
Message-Id: <87d2to3uwb.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Charlton Wilbur <cwilbur@chromatico.net>:
>> >>>>> "GM" == George Mpouras
>> >>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
>> >>>>> writes:
>>
>> >>> But what are you trying to achieve?
>>
>> GM> its a very big project , what you see here is a very small piece
>> GM> of code that expose the strange behaviour .
>>
>> GM> we had a very big headache to find what was wrong and where .
>>
>> The wrong thing is that you are trying to determine whether something is
>> a string or a number with foolish hackish approaches.
>
> You're making the same mistake as Dr.Ruud. I don't believe George was
> trying to determine whether a scalar was a string or a number, he was
> being bitten by the fact the bitops change their behaviour based on
> that.
Dispatching an abstract 'method invocation' to a specific 'method
implementation' based on the type of (some of) the arguments isn't a
particularly outlandish idea. And George actually already wrote what
he considered to be 'a bug', namely, the fact that a side-effect free
operation performed on a literal value causes that to change its type
because perl implicitly creates a scalar representing this literal
value and re-uses that for the 2nd invocation of the 'weird'
subroutine.
In the given context, that's an ill-conceived 'optimization hack',
even more so because it modifes a 'read only' value and yet more so
because this operation has been special-cased for 'undefined' values
to prevent them from becoming defined values in this way.
------------------------------
Date: Sun, 21 Apr 2013 17:35:55 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: This looks like a Perl bug
Message-Id: <87mwsrr2h0.fsf@new.chromatico.net>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth Charlton Wilbur <cwilbur@chromatico.net>:
>> The wrong thing is that you are trying to determine whether
>> something is a string or a number with foolish hackish
>> approaches.
BM> You're making the same mistake as Dr.Ruud. I don't believe
BM> George was trying to determine whether a scalar was a string or
BM> a number,
In the absence of George saying why he is writing opaque and convoluted
code, we are left to infer and commit the intentional fallacy.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 21 Apr 2013 16:56:40 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: This looks like a Perl bug
Message-Id: <kl1uq9$bq4$3@dont-email.me>
On 04/21/2013 02:35 PM, Charlton Wilbur wrote:
>>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>
> BM> Quoth Charlton Wilbur <cwilbur@chromatico.net>:
>
> >> The wrong thing is that you are trying to determine whether
> >> something is a string or a number with foolish hackish
> >> approaches.
>
> BM> You're making the same mistake as Dr.Ruud. I don't believe
> BM> George was trying to determine whether a scalar was a string or
> BM> a number,
>
> In the absence of George saying why he is writing opaque and convoluted
> code, we are left to infer and commit the intentional fallacy.
>
There is no doubt as to why he is writing that code. It is because it
exhibits the behavior he believes to be a bug. He was pretty explicit
about that. Your refusal to understand the obvious makes me ponder your
intention, perhaps fallaciously.
Xho
------------------------------
Date: Sun, 21 Apr 2013 06:50:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: timeout a print to stdout?
Message-Id: <1bbc4a-te01.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> "Dave Saville" <dave@invalid.invalid> writes:
>
> > eval
> > {
> > local $SIG{ALRM} = sub{die "too long" };
> > alarm 60;
> > print $buffer;
> > alarm 0;
> > };
> > exit if $@ =~ m{^too long};
<here we go again> Testing $@ after an eval is not safe in the general
case, since destructors can end up clearing it. (It's possible this has
been fixed in a current version of perl; I haven't been keeping up...)
Use Try::Tiny instead.
> > }
> >
> > 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 ...
If OS/2 supports SIGALRM at all it will be deferred, yes. Whether or not
this will interrupt the write(2)-or-equivalent depends on the OS. Use
POSIX::sigaction to install an 'unsafe' signal handler, and be careful
about what that handler does (dying with a constant string should be
safe).
Ben
------------------------------
Date: Sun, 21 Apr 2013 00:21:59 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: timeout a print to stdout?
Message-Id: <kl042r$c5e$1@speranza.aioe.org>
On 4/20/2013 7:07 AM, Dave Saville wrote:
> 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?
>
Normally, you'd wrap the long running operation within the eval {};
my $rc = 1;
eval {
local $SIG{ALRM} = sub { die "too long"; };
alarm 60;
while ($rc) {
read( ... );
die $! unless defined $rc;
}
alarm 0;
};
die $@ if $@;
There are race conditions so I'd encourage rewriting this to use
the suggested Try::Tiny which will handle common eval gotcha's.
While debugging, it can be helpful to see what happens:
# use following only during debug
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
...
warn "debug: ....";
--
Charles DeRykus
------------------------------
Date: Sun, 21 Apr 2013 14:00:05 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: timeout a print to stdout?
Message-Id: <878v4c3up6.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 4/20/2013 7:07 AM, Dave Saville wrote:
[...]
>> open my $STREAM, '<', "t:/tmp/Foo.rec" or die $!;
[...]
>> 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};
>> }
[...]
> Normally, you'd wrap the long running operation within the eval {};
>
> my $rc = 1;
> eval {
> local $SIG{ALRM} = sub { die "too long"; };
> alarm 60;
> while ($rc) {
> read( ... );
> die $! unless defined $rc;
> }
> alarm 0;
> };
> die $@ if $@;
David did that: The operation which could just 'block forever' is the
print which sends data over a network connection, not the read from a
local file. In fact, reads from files are (on UNIX(*)) not even
interruptible because they are not considered 'blocking operations' in
the sense of 'may wait forever for an external event which never
happens'.
------------------------------
Date: Sun, 21 Apr 2013 16:44:55 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: timeout a print to stdout?
Message-Id: <fV45K0OBJxbE-pn2-WZ3Ft7Td0yvm@paddington.bear.den>
On Sat, 20 Apr 2013 16:45:16 UTC, Rainer Weikusat
<rweikusat@mssgmbh.com> wrote:
> "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
>
Well I did say irt was quick and dirty :-)
> die $! unless defined($rc)
>
> or
>
> $rc // die $!
>
> Because of this, your script should really exit after the first
> iteration ...
>
Which it doesn't.
> > 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 ...
That looks interesting. Never heard of that thanks.
--
Regards
Dave Saville
------------------------------
Date: Sun, 21 Apr 2013 18:01:58 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: timeout a print to stdout?
Message-Id: <87r4i3bywp.fsf@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> On Sat, 20 Apr 2013 16:45:16 UTC, Rainer Weikusat
>> "Dave Saville" <dave@invalid.invalid> writes:
[...]
>> > 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
>>
>
> Well I did say irt was quick and dirty :-)
The problem is not that it would be 'quick and dirty' but totally
wrong because undef is not a predicate.
>> die $! unless defined($rc)
>>
>> or
>>
>> $rc // die $!
>>
>> Because of this, your script should really exit after the first
>> iteration ...
>>
>
> Which it doesn't.
When I run the code below
----------------------------
use strict;
use warnings;
print "Content-type: text/plain\n\n";
open my $STREAM, '<', "/var/log/syslog" 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};
}
----------------------------
on the system I'm using to write this, it does exit after printing the
first 4096-byte block of the /var/log/syslog file ...
------------------------------
Date: Sun, 21 Apr 2013 14:35:24 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: timeout a print to stdout?
Message-Id: <kl1m2t$v3f$1@speranza.aioe.org>
On 4/21/2013 6:00 AM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 4/20/2013 7:07 AM, Dave Saville wrote:
>
> [...]
>
>>> open my $STREAM, '<', "t:/tmp/Foo.rec" or die $!;
>
> [...]
>
>>> 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};
>>> }
>
> [...]
>
>> Normally, you'd wrap the long running operation within the eval {};
>>
>> my $rc = 1;
>> eval {
>> local $SIG{ALRM} = sub { die "too long"; };
>> alarm 60;
>> while ($rc) {
>> read( ... );
>> die $! unless defined $rc;
>> }
>> alarm 0;
>> };
>> die $@ if $@;
>
> David did that: The operation which could just 'block forever' is the
> print which sends data over a network connection, not the read from a
> local file.
Ah, I missed the real stream. One other possible solution,
if the problem is intractable, is to fork a child process
which just sets an alarm and then kills the parent when it
goes off.
In fact, reads from files are (on UNIX(*)) not even
> interruptible because they are not considered 'blocking operations' in
> the sense of 'may wait forever for an external event which never
> happens'.
>
Yes, I've read it too and I'm presuming that actually means
individual I/O op's on a disk file are atomic and won't be
interrupted. However it is still possible to timeout reading
a large disk file with an alarm.
--
Charles DeRykus
------------------------------
Date: Mon, 22 Apr 2013 09:28:29 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: timeout a print to stdout?
Message-Id: <fV45K0OBJxbE-pn2-WqNdDPNn1hdK@paddington.bear.den>
On Sun, 21 Apr 2013 17:01:58 UTC, Rainer Weikusat
<rweikusat@mssgmbh.com> wrote:
> "Dave Saville" <dave@invalid.invalid> writes:
> > On Sat, 20 Apr 2013 16:45:16 UTC, Rainer Weikusat
> >> "Dave Saville" <dave@invalid.invalid> writes:
>
> [...]
>
> >> > 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
> >>
> >
> > Well I did say irt was quick and dirty :-)
>
> The problem is not that it would be 'quick and dirty' but totally
> wrong because undef is not a predicate.
>
> >> die $! unless defined($rc)
> >>
> >> or
> >>
> >> $rc // die $!
> >>
> >> Because of this, your script should really exit after the first
> >> iteration ...
> >>
> >
> > Which it doesn't.
>
> When I run the code below
>
> ----------------------------
> use strict;
> use warnings;
> print "Content-type: text/plain\n\n";
> open my $STREAM, '<', "/var/log/syslog" 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};
> }
> ----------------------------
>
> on the system I'm using to write this, it does exit after printing the
> first 4096-byte block of the /var/log/syslog file ...
Nope hung around forever here. If it had exited that fast I might have
spotted my error re undef. :-) I was sending a video stream and it
would be pretty obvious if the player only got the first 4096 bytes.
In any case it is now moot as I have found an alternative method of
solving the original, unspecified and unrelated to perl, problem. I
don't know what I was thinking when I coded that line. The number of
times I have written if ! defined...................
--
Regards
Dave Saville
------------------------------
Date: Mon, 22 Apr 2013 15:20:05 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: timeout a print to stdout?
Message-Id: <87ip3e7ilm.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 4/21/2013 6:00 AM, Rainer Weikusat wrote:
[...]
>> In fact, reads from files are (on UNIX(*)) not even interruptible
>> because they are not considered 'blocking operations' in the sense
>> of 'may wait forever for an external event which never happens'.
>
> Yes, I've read it too and I'm presuming that actually means
> individual I/O op's on a disk file are atomic and won't be
> interrupted.
'Disk I/O ops' are something the kernel does asynchronously 'when it feels
like that' and they are invisble to applications: These always either
write to memory buffers or read from memory buffers. In case an
application wants to 'read' data which isn't already in core, it is
put into 'uninterruptible sleep' (Linux term) until the data became
available (there might be exception for 'some network file system', eg
there used to be [on Linux, again] an 'intr' mount option to enable operations on
NFS-mounted shared to be interruptible but this has been turned into a
no-op with Linux 2.6.25).
> However it is still possible to timeout reading a large disk file
> with an alarm.
Only if 'the [application] I/O operation' returns into user-mode in
between, eg, because an intermediate buffering layer (like stdio or
perlio) is reading a 'large' amount of data in relatively small,
fixed-size chunks.
------------------------------
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 3930
***************************************
