Erland Sommarskog ([EMAIL PROTECTED]) writes:
> But I can find any corresponding to BOOT for when the script exists.
> There is DESTROY, but that is for an object, and a thread may create
> more than one object. (And it may for some reason create no object at
> all.)
OK, there was an easy out: add an END section in the PM module. This
appears to run well when you run it in a context of PerlScript from
something like ISAPI or DTS.
But! this doesn't fly when you run a Perl script with C<use threads> in
it which looks something like this:
use strict;
use threads;
my @threads;
foreach my $i (0..9) {
push(@threads, threads->create(\&testsubba, $i));
}
foreach my $t (@threads) {
$t->join();
}
exit;
sub testsubba {
my ($ix) = @_;
require 'MSSQL/DBlib.pm';
my $X = MSSQL::DBlib::dblogin();
}
This fails, because the END section of DBlib.pm is not run by the
worker thread, but the main thread of the program. This smells "bug"
to me, but I could be wrong.
Now, as I said in my previous post, I do not use the built-in XS macros
for thread-local storage, but use Win32 routines, so I'm not playing by
the book. I never tried the XS things of pure laziness: I want my module
to compile on earlier Perl versions too.
There are more ways to approach this, but I've decided to quit, because
I don't have any need myself for the modules being possible to run from
Perl threads, and I have not heard anyone else asking for this. (Whereas
people really have had problems with the modules in ISAPI and DTS.)
--
Erland Sommarskog, Stockholm, [EMAIL PROTECTED]
