Which sometimes yields:#!/usr/bin/perl use warnings; use strict; use threads; use threads::shared; my %hash :shared; sub dumper { my $h = shift; my $ret = "{\n"; while (my ($k,$v) = each %$h) { $ret.= "\t$k => $v\n"; } $ret.= "}\n"; return $ret; } sub sub1 { my $str = '[s'.threads->tid()."]\n"; $str.= dumper \%hash; $str.= '[e'.threads->tid()."]\n"; return $str; } $hash{a} = 1; my $th1 = threads->new('sub1'); $hash{b} = 2; my $th2 = threads->new('sub1'); my $a = $th1->join(); my $b = $th2->join(); print STDERR $a; print STDERR $b;
And I just reproduced it on perl 5.8.5 32 and 64bit linux. Sometimes I also get:[s1] { a => 1 b => 2 a => 1 b => 2 } [e1] [s2] { a => 1 } [e2]
Then again, even though we see duplicate keys, their value is correct... Maybe the problem arises when trying to cycle through all keys of the hash at the exact same time its contents are being updated: If I add a select undef,undef,undef,0.01; between the two thread spawns, I never see duplicate keys. At the worst I see normal differences between $a and $b.[s1] { a => 1 b => 2 b => 2 } [e1] [s2] { a => 1 a => 1 b => 2 } [e2]
In reply to Re^18: does threads (still) memleak?
by faxm0dem
in thread does threads (still) memleak?
by faxm0dem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |