[26324] in Perl-Users-Digest
Perl-Users Digest, Issue: 8499 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 8 03:05:21 2005
Date: Sat, 8 Oct 2005 00:05:06 -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, 8 Oct 2005 Volume: 10 Number: 8499
Today's topics:
Re: print prints things in strange order. <tadmc@augustmail.com>
Re: SNMP.pm <glex_no-spam@qwest-spam-no.invalid>
Re: threads, XSUB allocated memory, destructors, destru <sisyphus1@nomail.afraid.org>
Re: threads, XSUB allocated memory, destructors, destru <tassilo.von.parseval@rwth-aachen.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 7 Oct 2005 17:42:37 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: print prints things in strange order.
Message-Id: <slrndkduet.64g.tadmc@magna.augustmail.com>
Robbie Hatley <bogus.email@no.spam.com> wrote:
> I think I'll alter chomp in the Perl source and recompile.
That is absurd.
Try putting this near the top of the program that must process
DOS style files while running on a Unix style system:
local $/ = "\015\012";
You can read about the $/ variable in:
perldoc perlvar
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 07 Oct 2005 17:23:41 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: SNMP.pm
Message-Id: <NzC1f.436$o93.554@news.uswest.net>
Warrick FitzGerald wrote:
> Ok sorry I was trying to simplify my problem, but here's the real situation:
>
> When running snmptt, I get the same error
>
> [root@Uploads wfitzgerald]# /usr/sbin/snmptt
> --ini=/etc/snmptt/snmptt.ini --debug2
> Unknown option: debug2
> Config file /etc/snmptt/snmptt.ini loaded
> Can't locate SNMP.pm in @INC (@INC contains:
> /usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1
> /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0
> /usr/lib/perl5/vendor_perl .) at (eval 2) line 1.
>
> Could not load the Perl module SNMP! If net_snmp_perl_enable is
> enabled then the SNMP module is required. Please see snmptt.html
> for system requirements. Note: SNMPTT uses the Net-SNMP package's
> SNMP module, NOT the CPAN Net::SNMP module!
OK. It's not installed, or installed in a location that's not part of
the default @INC.
I've never heard of it, but looking around the Internet brought me to
the FAQ, which explains how to install Net-SNMP.
http://snmptt.sourceforge.net/docs/faqs.shtml
I'd suggest installing the Net-SNMP module mentioned. Once it's
installed correctly, it should resolve that error.
------------------------------
Date: Sat, 8 Oct 2005 08:34:55 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: threads, XSUB allocated memory, destructors, destruction
Message-Id: <4346f865$0$11682$afc38c87@news.optusnet.com.au>
"Tassilo v. Parseval"
.
.
> Cloning happens with every variable showing up in a threaded program
> (unless it's shared).
>
Or unless CLONE_SKIP() returns 1.
I haven't explained my confusion very well. Setting CLONE_SKIP fixes the
problem by preventing the cloning. But looks to me that the cloning is not
the real problem - it's the DESTROY() that gets called that does the
damage - which makes CLONE_SKIP a workaround, rather than a fix (... I know
... it's a moot distinction). Perhaps the correct way to fix the problem is
to do something appropriate within the 'CLONE' subroutine - though I don't
know what that "something appropriate" actually is. The perlmod docs seems
to be saying that is the purpose of the CLONE subroutine:
"In "CLONE" you can do whatever you need to do, like for example handle the
cloning of non-Perl data, if necessary."
Looking at it another way:
If it's ok that unblessed objects be cloned, then it ought to be ok that
blessed objects also be cloned.
Is it possible to prevent cloning of unblessed objects ? Does CLONE_SKIP
work in a script that doesn't declare a package name ? (ie does it work in
package main ? How would one verify ?)
Cheers,
Rob
------------------------------
Date: Sat, 8 Oct 2005 07:57:45 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: threads, XSUB allocated memory, destructors, destruction
Message-Id: <slrndkenup.sk.tassilo.von.parseval@localhost.localdomain>
Also sprach Sisyphus:
> "Tassilo v. Parseval"
> .
> .
>> Cloning happens with every variable showing up in a threaded program
>> (unless it's shared).
>>
>
> Or unless CLONE_SKIP() returns 1.
> I haven't explained my confusion very well. Setting CLONE_SKIP fixes the
> problem by preventing the cloning. But looks to me that the cloning is not
> the real problem - it's the DESTROY() that gets called that does the
> damage - which makes CLONE_SKIP a workaround, rather than a fix (... I know
> ... it's a moot distinction). Perhaps the correct way to fix the problem is
> to do something appropriate within the 'CLONE' subroutine - though I don't
> know what that "something appropriate" actually is. The perlmod docs seems
> to be saying that is the purpose of the CLONE subroutine:
>
> "In "CLONE" you can do whatever you need to do, like for example handle the
> cloning of non-Perl data, if necessary."
The tricky part about that is that CLONE is not an instance method so
it's not called per object that is about to be cloned.
> Looking at it another way:
> If it's ok that unblessed objects be cloned, then it ought to be ok that
> blessed objects also be cloned.
>
> Is it possible to prevent cloning of unblessed objects ? Does CLONE_SKIP
> work in a script that doesn't declare a package name ? (ie does it work in
> package main ? How would one verify ?)
CLONE and CLONE_SKIP are run for each stash, and that should include
main::. The problem with having main::CLONE_SKIP is that then no
variable is cloned any longer, not even regular Perl types with no
attached XSUB-logic.
I don't have a recent enough threaded perl right now to test what
happens in such a case. I assume that then all variables are essentially
shared but without any mechanism of mutual exclusive access to them. In
essence, your program should have a high likelihood of blowing up
terribly.
As for CLONE and how to use that, here's one example. CLONE is run in
the context of the newly created thread. The idea of the code below is
now to have CLONE mark the cloned variable as non-freeable with respect
to that thread. I abuse the SVf_FAKE flag (renamed to SVf_DONT_FREE) for
the mark since it's not going to be set by perl for the variable to be
cloned:
#!/usr/bin/perl -w
use threads;
package Experimental;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'EOC';
#define SVf_DONT_FREE SVf_FAKE
SV * create_obj (int x) {
int *int_obj;
SV *obj;
New(0, int_obj, x, int);
obj = sv_setref_pv(newSV(0), "Experimental", (void*)int_obj);
return obj;
}
void dont_free (SV *obj) {
SvFLAGS(SvRV(obj)) |= SVf_DONT_FREE;
}
void DESTROY (SV *obj) {
if (SvFLAGS(SvRV(obj)) & SVf_DONT_FREE) {
printf("not freeing\n");
return;
}
printf("freeing\n");
Safefree((int*)SvIV(SvRV(obj)));
}
EOC
my @array = map create_obj(rand 10), 1 .. 5;
sub CLONE {
dont_free($_) for @array;
}
my @t = map threads->new("run", @array), 1 .. 2;
$_->join for @t;
sub run {
for (@_) {
printf "%i / %i\n", threads->tid, $_;
}
}
__END__
1 / 137794056
1 / 137801572
1 / 137801596
1 / 137801620
1 / 137801644
2 / 138506624
2 / 138514140
2 / 138514164
2 / 138514188
2 / 138514212
not freeing
not freeing
not freeing
not freeing
not freeing
not freeing
not freeing
not freeing
not freeing
not freeing
freeing
freeing
freeing
freeing
freeing
This solution is not entirely satisfactory because the cloneable
variables in question need to be visible for CLONE. But by and large
this should be adaptable enough to be used in threaded programs that
make use of classes written in XS.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 8499
***************************************
