I too don't like Perl 5.8.2 threads

(aka. Joining the "Perl 5.8.2 threads are much worse" cult)

I would just like to add something to the two previous meditations regarding Perl 5.8.2 threading being much worse than earlier 5.8 versions but started a new meditation as it's my first one :) Ok, that, and I'm dealing with databases.

Certain people may have noticed that I am having a few troubles with Perl 5.8.2, threading and Oracle 9i database connections under Solaris 8 (for sparc).

After recent advice from a member of the Perl DBI mailing list I built Perl 5.8.0 with threading support and compared the results against Perl 5.8.2 threads.

Code snippet 1:

#!/opt/bin/perl

use threads;
use DBI;

@threads;
printf "Starting thread ";
for ($i = 0; $i < 50; $i++) {
        printf "$i ";
        $threads[$i] = new threads(\&do_db);
}
printf "\n";

printf "Joining thread ";
for ($i = 0; $i < 50; $i++) {
        printf "$i ";
        $thread = $threads[$i];
        $thread->join;
}
printf "\n";

sub do_db {
        my $dbh = DBI->connect("dbi:Oracle:host=localhost;sid=testdb1"
+, "user1", "pass1") || die $!;
}
[download]

under 5.8.2 started all threads but then core dumped when trying to join. Under 5.8.0 this code seems to work fine.

Code snippet 2:

#!/opt/bin/perl

use threads;
use DBI;

our $orashr : shared = '' ;

@threads;
printf "Starting thread ";
for ($i = 0; $i < 50; $i++) {
        printf "$i ";
        $threads[$i] = new threads(\&do_db);
}
printf "\n";

printf "Joining thread ";
for ($i = 0; $i < 50; $i++) {
        printf "$i ";
        $thread = $threads[$i];
        $thread->join;
}
printf "\n";

sub do_db {
        my $dbh = DBI->connect("dbi:Oracle:host=localhost;sid=testdb1"
+, "user1", "pass1", { ora_dbh_share => \$orashr} ) || die $!;
}
[download]

under 5.8.2 core dumped after only starting a handful of threads. Under 5.8.0 it starts all the threads fine but then dumps core when trying to join them.

I am most interested in the latter code and as it still dumps core Perl 5.8 threads are of no use to me. Yet. However, I believe this does highlight one thing - the behaviour under 5.8.0 threads compared to 5.8.2 threads is better. Things either don't crash, or crash at a later point, but things work better.

I wonder why threads in 5.8.2 are causing so much bother...

== fx, Infinity Is Colourless

Comment on I too don't like Perl 5.8.2 threads Select or Download Code

Replies are listed 'Best First'.
Re: I too don't like Perl 5.8.2 threads by mpeppler (Vicar) on Jan 06, 2004 at 20:15 UTC
I can now reproduce your problem using your first code snippet, both on 5.8.2 and 5.8.1. The code dies here, in pad.c (Perl_pad_undef()): /* detach any '&' anon children in the pad; if afterwards they * are still live, fix up their CvOUTSIDEs to point to our outside +, * bypassing us. / / XXX DAPM for efficiency, we should only do this if we know we h +ave * children, or integrate this loop with general cleanup / if (!PL_dirty) { / don't bother during global destruction / CV outercv = CvOUTSIDE(cv); U32 seq = CvOUTSIDE_SEQ(cv); AV comppad_name = (AV)AvARRAY(padlist)[0]; SV *namepad = AvARRAY(comppad_name); AV comppad = (AV)AvARRAY(padlist)[1]; SV curpad = AvARRAY(comppad); for (ix = AvFILLp(comppad_name); ix > 0; ix--) { SV namesv = namepad[ix]; if (namesv && namesv != &PL_sv_undef /* DIES HERE / && SvPVX(namesv) == '&') { [download] This code is identical in both 5.8.1 and 5.8.2. Now I need to check 5.8.0 to see what has changed. UPDATE: The pad.c file (and associated functions) is new in 5.8.1... So it won't be a question of doing a simple diff :-(. I guess that this is one for the perl5-porters list... Michael	[reply] [d/l]
Re: I too don't like Perl 5.8.2 threads by mpeppler (Vicar) on Jan 06, 2004 at 22:54 UTC
The following patch to perl-5.8.2/pad.c fixes the segfault problem for me. `* pad.c~ Tue Sep 30 10:11:42 2003 --- pad.c Tue Jan 6 13:58:53 2004 *********** * 242,247 **** --- 242,248 ---- for (ix = AvFILLp(comppad_name); ix > 0; ix--) { SV namesv = namepad[ix]; if (namesv && namesv != &PL_sv_undef + && SvPOK(namesv) && SvPVX(namesv) == '&') { CV innercv = (CV)curpad[ix];` [download] It's probably not the right patch, but maybe it'll point the maintainers in the right direction... Michael	[reply] [d/l]
Re: I too don't like Perl 5.8.2 threads by mpeppler (Vicar) on Jan 06, 2004 at 19:21 UTC
I looked at the code for ora_dbh_share in the DBD::Oracle sources after seeing your message(s) on the DBI mailing list, and there's some pretty heavy magic going on in there. I'm not particularily surprised that it has broken with 5.8.2. I'm currently working on thread-enabling DBD::Sybase, and I have some code that appears to work correctly with 5.8.1. I'm bulding 5.8.2 now to see if it'll work for me (tested with 15 threads issuing thousands of database requests concurrently under linux with Sybase 12.5.1.) Note however that I won't attempt to share database handles between threads. Michael	[reply]
Re: I too don't like Perl 5.8.2 threads by castaway (Parson) on Jan 06, 2004 at 17:55 UTC
Hmm.. havent tried your code, but maybe its either that DBI/DBD::Oracle isnt thread aware, or just that trying to connect to Oracle 50 times more or less simultaneously is buggy.. You could try putting a sleep(rand(20)) in that do_db sub, and see if that helps. Im not quite sure what that second snippet is trying to do with the $orashr variable, but if its passing it to get the dbh set as a shared variable, its probably not going to work, because of the problems sharing objects.. C.	[reply]
Re: Re: I too don't like Perl 5.8.2 threads by fx (Pilgrim) on Jan 06, 2004 at 21:20 UTC
maybe its either that DBI/DBD::Oracle isnt thread aware One of my previous posts references both the `DBI` and the `DBD::Oracle` docs and the fact that they both should be thread safe with Perl 5.8.something. Im not quite sure what that second snippet is trying to do with the $orashr variable Basically, the `DBD::Oracle docs` describes the `$orashr` var as a way to share a single db connection across multiple threads.	[reply]