Skip Menu |

This queue is for tickets about the threads-shared CPAN distribution.

Report information
The Basics
Id: 18973
Status: rejected
Priority: 0/
Queue: threads-shared

People
Owner: Nobody in particular
Requestors: jgmyers [...] proofpoint.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.01
Fixed in: (no value)



Subject: variables defined after threads created not shared
As demonstrated by the attached test case, shared variables that are defined after threads have already been cloned are not correctly shared. Instead, each of the existing threads gets its own private copy of the "shared" variable. (In my application, it is sometimes the case that it doesn't know to load a module until well after the application has gone multithreaded.)
Subject: perl-shared.pl
use strict; use warnings; use threads; use threads::shared; use Thread::Queue; our $q = new Thread::Queue; sub doload { eval <<'EOT' package child; use strict; use warnings; use threads; use threads::shared; our $var : shared; sub process { lock($var); $var = 0 unless defined($var); print "$var\n"; ++$var; } EOT ; } sub child { &doload(); $q->dequeue(); child::process(); } our @thr; #&doload(); foreach my $i (1..5) { push @thr, scalar threads->create('child'); } &doload(); foreach my $i (1..5) { $q->enqueue($i); } foreach my $t (@thr) { $t->join(); }
Subject: Re: [rt.cpan.org #18973] variables defined after threads created not shared
Date: Fri, 28 Apr 2006 16:03:25 -0700
To: bug-threads-shared [...] rt.cpan.org
From: Artur Bergman <sky [...] nanisky.com>
I am not sure what the correct semantics should be here, the variable doesn't exist so how can the other thread have access ot them? Artur On 28 Apr 2006, at 11:26, Guest via RT wrote: Show quoted text
> > Fri Apr 28 14:26:04 2006: Request 18973 was acted upon. > Transaction: Ticket created by guest > Queue: threads-shared > Subject: variables defined after threads created not shared > Owner: Nobody > Requestors: jgmyers@proofpoint.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18973 > > > > As demonstrated by the attached test case, shared variables that are > defined after threads have already been cloned are not correctly > shared. > Instead, each of the existing threads gets its own private copy of > the > "shared" variable. > > (In my application, it is sometimes the case that it doesn't know to > load a module until well after the application has gone > multithreaded.) > > use strict; > use warnings; > use threads; > use threads::shared; > use Thread::Queue; > > our $q = new Thread::Queue; > > sub doload { > eval <<'EOT' > package child; > > use strict; > use warnings; > use threads; > use threads::shared; > our $var : shared; > > sub process { > lock($var); > $var = 0 unless defined($var); > print "$var\n"; > ++$var; > } > EOT > ; > } > > sub child { > &doload(); > $q->dequeue(); > child::process(); > } > > our @thr; > > #&doload(); > > foreach my $i (1..5) { > push @thr, scalar threads->create('child'); > } > > &doload(); > > foreach my $i (1..5) { > $q->enqueue($i); > } > > foreach my $t (@thr) { > $t->join(); > }
From: jgmyers [...] proofpoint.com
On Fri Apr 28 19:05:10 2006, sky@nanisky.com wrote: Show quoted text
> I am not sure what the correct semantics should be here, the variable > doesn't exist so how can the other thread have access ot them?
The other threads should get access when they eval the "our $var : shared;" It should notice there is already an existing shared sv named $child::var and make that thread's $child::var use the same backing shared sv. All shared variables with the same name should have the same backing shared-space sv.
Subject: Re: [rt.cpan.org #18973] variables defined after threads created not shared
Date: Fri, 28 Apr 2006 17:52:06 -0700
To: bug-threads-shared [...] rt.cpan.org
From: Artur Bergman <sky [...] nanisky.com>
On 28 Apr 2006, at 16:22, Guest via RT wrote: Show quoted text
> > The other threads should get access when they eval the "our $var : > shared;" > It should notice there is already an existing shared sv named > $child::var and make that thread's $child::var use the same backing > shared sv. > > All shared variables with the same name should have the same backing > shared-space sv.
I am tempted to say, patches welcome, but the implications seem bad. My argument would be that : shared is a compile time option, and threads are a compile time options. eval "use threads;" is not support, so neither is eval " : shared " Artur
From: jgmyers [...] proofpoint.com
On Fri Apr 28 20:53:47 2006, sky@nanisky.com wrote: Show quoted text
> My argument would be that : shared is a compile time option, and > threads are a compile time options.
The test case was simplified to fit into a single file. The bug can also be demonstrated by putting the "package child" definitions into a separate child.pm file and replacing the eval with a "require child;" I haven't figured out how the shared attribute results in a call to the threads::shared module, so I don't know what I'd start patching.
Subject: Re: [rt.cpan.org #18973] variables defined after threads created not shared
Date: Fri, 28 Apr 2006 18:50:09 -0700
To: bug-threads-shared [...] rt.cpan.org
From: Artur Bergman <sky [...] nanisky.com>
On 28 Apr 2006, at 18:21, Guest via RT wrote: Show quoted text
> > Queue: threads-shared > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18973 > > > On Fri Apr 28 20:53:47 2006, sky@nanisky.com wrote:
>> My argument would be that : shared is a compile time option, and >> threads are a compile time options.
> > The test case was simplified to fit into a single file. The bug can > also be demonstrated by putting the "package child" definitions into a > separate child.pm file and replacing the eval with a "require child;" > > I haven't figured out how the shared attribute results in a call to > the > threads::shared module, so I don't know what I'd start patching. >
require and eval "" are essentially the same thing artur
From: jgmyers [...] proofpoint.com
Show quoted text
> require and eval "" are essentially the same thing
And both compile their respective arguments as one step of their processing. So I don't see how saying something is "a compile time option" is making any distinction. "use threads;" works just fine under eval/require--what says it isn't supported? The threads POD only says one can't create a thread during the compilation phase.
From: jgmyers [...] proofpoint.com
As further proof that eval is not the problem, if you uncomment the commented call to &doload() in the test program then the test program exhibits correct behavior.
Subject: Re: [rt.cpan.org #18973] variables defined after threads created not shared
Date: Sat, 29 Apr 2006 12:09:58 -0700
To: bug-threads-shared [...] rt.cpan.org
From: Artur Bergman <sky [...] nanisky.com>
On 28 Apr 2006, at 21:55, Guest via RT wrote: Show quoted text
> > Queue: threads-shared > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=18973 > >
>> require and eval "" are essentially the same thing
> > And both compile their respective arguments as one step of their > processing. So I don't see how saying something is "a compile time > option" is making any distinction. > > "use threads;" works just fine under eval/require--what says it isn't > supported? The threads POD only says one can't create a thread during > the compilation phase. >
Uhm, I did when I wrote it. require is compile time for that unit yes, but if you compile something after a thread is created it only exists in that interpreter, so it is per default ... Artur
From: Jerry D. Hedden
Show quoted text
> "use threads;" works just fine under eval/require--what says it isn't > supported? The threads POD only says one can't create a thread during > the compilation phase.
From the 'threads' POD: It is also important to note that you must enable threads by doing C<use Show quoted text
threads> as early as possible in the script itself, and that it is not
possible to enable threading inside an C<eval "">, C<do>, C<require>, or C<use>. In particular, if you are intending to share variables with L<threads::shared>, you must C<use threads> before you C<use threads::shared>. (C<threads> will emit a warning if you do it the other way around.) Also 'perldoc -f our' states: "our" associates a simple name with a package variable in the current package, for use within the current scope. Each child thread has its own scope. When 'our $var : shared' is 'eval'ed it creates a new version of the variable that is visible only to that thread. Therefore, there is no bug.