> Steven W McDougall wrote:
> > > The more interesting case is this:
> > >
> > > #!/my/path/to/perl
> > > sub foo_generator { my $a = shift; sub { print $a++ } }
> > > my $foo = foo_generator(1);
> > > $foo->();
> > > Thread->new($foo);
> >
> > > Is $a shared between threads or not?
> >
> > $a is shared between threads.
> > The anonymous subroutine is a closure.
> > Closures work across threads.
>
> That's a possibility, but it has severe implementation problems --
> all closures must be treated as having shared variables. That makes
> closures really expensive. The use of "our" vs. "my" for mutex locking
> becomes (almost) useless.
How do `our' and `my' control mutex locking?
You don't need closures to share block-scoped lexicals across threads.
All you have to do is pass a reference into a threaded subroutine.
sub foo
{
my $a;
Thread->new(\&bar, \$a);
$a++;
}
sub bar
{
my $a = shift;
$$a++;
}
or just declare one subroutine within the scope of another
sub foo
{
my $a;
Thread->new(\&bar);
$a++;
sub bar
{
$$a++;
}
}
> If I change the above code to:
>
> #!/my/path/to/perl
> sub foo_generator { our $a = shift; sub { print $a++ } }
> ###
> my $foo = foo_generator(1);
> $foo->();
> Thread->new($foo);
>
> then I'd expect $a to be shared. I'm not so sure otherwise -- the
> performance cost might be too big.
In this example, does `our' have the Perl 5.6.0 semantics, or some new
semantics that controls whether variables are shared between threads?
- SWM
