develooper Front page | perl.perl5.porters | Postings from February 2003

Re: [perl #18346] Signal handler broken using ithreads

Thread Previous | Thread Next
Nick Ing-Simmons
February 4, 2003 05:16
Re: [perl #18346] Signal handler broken using ithreads
Message ID:
Dan Sully <> writes:
>* Nick Ing-Simmons <> shaped the electrons to say...
>> >That seems like broken behavior.
>> In hindsight I agree - it has turned out that there are more bugs and snags
>> in :stdio wrapper than in the :perlio re-write. The default may be changed
>>     in 5.8.1
>Thanks for the explantion. I would put my vote in for
>"When I select perlio at compile time, really use it".
>Is there any way inside of a program/module to say the equivalent of
>'PERLIO=true' ?

As I said before - value of $ENV{PERLIO} is name of layer(s) to use
so it would not be PERLIO=true.

It was supposed to be possible to set this stuff up on a program/module 
basis using the "open" pragma:

use open IO => ':perlio';

Or equivalent  on command line :
#!.../perl -Mopen=... 

But that does not seem to be working right either :-(
It adds :perlio _ON TOP_ of :stdio which is not what we want here.

(p5p - I know I never liked but it seems its parsing has got even 
more messy than I remember it. As far as I recall ':' was supposed 
to be a separator (like $ENV{PATH} or attributes my $foo : shared : lock )
but seems to be spliting on whitespace and then treating : as
prefix to the name.
The mis-feature above is not caused by this dubious parsing but the parsing
does make commandline does not seem to allow -Mopen=:foo:bar but 
requires -Mopen=':foo :bar'

Nick Ing-Simmons

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About