Proper Way to Provide Variable to Objects below the present calling subroutine? - multithreading

Question

In my code base, I have several variables that "live" in the main namespace and various modules I utilize can expect to always find in main (for example, $main::author is a reference to a hash about the user, $main::dbh is the open database handle, $main::loader is an object of a core utility class and $main::FORM has the processed QUERY_STRING). E.g. when the program starts up:
$main::author = &getAuthor;
$main::loader = SAFARI::Loader->new;
use SAFARI::View;
my $view = SAFARI::View->new;
$view->output;
And then when I'm in SAFARI::View::output, I can call on those core variables, e.g.:
# Display user name:
$output .= 'Hello, ' . $main::author->{'fullName'} . '! Welcome!';
The problem: when the code is running in a threaded environment, one thread may need a different $loader object or have a different $author logged in than the other thread. More pressingly still, each thread has, of course, a different database handle.
I know I could pass along the core information when creating objects such as View by adding parameters it takes. But that means every type of object that presently can just reference these items in the main namespace must have a lengthy list of parameters instead. I'm trying to think of the most efficient and "safe" way to solve this problem.
I've considered creating a hash reference that has all the different bits in it within each thread, e.g. $common that has $common->{'FORM'}, $common->{'loader'}, $common->{'author'}, etc., and then pass those as a single argument to each object:
my $common = #Logic to set up this combination of bits for this particular thread.
my $view = SAFARI::View->new({ 'common' => $common });
my $article = SAFARI::Article->new({ 'common' => $common });
my $category = SAFARI::Category->new({ 'common' => $common });
That's not too tedious, but it still seems inefficient; it'd be preferable if the "environment" of just that thread could contain something that object within in it could access. As far as I can tell, declaring our $common within the subroutine that is run by the thread would do this and any objects created within that subroutine would have access to that variable. Is there any harm in this approach?
It seems like it would be cleaner to have these items in some sort of namespace, but if I refer to, say, $SAFARI::common, that name space would reach across threads just like main does. Would having $SAFARI::common but then declaring a local variant of it in each thread be reasonable?
Is there a "best practice" for what I'm trying to do? It's going to take some significant reworking of code to fix this one way or another, so I'd really like to get it "right."

Answer 1

This is a complex question, with multiple major components.
For starters, there is a question of how to pass an initial data-structure to threads so that they can use it, but without it being shared.
In Perl, when threads are created the existing data are copied to each thread. That's why it's often a good idea to create threads right up front, before there's much data in the program, to avoid those threads being bloated. The copied data is not shared, by default, in Perl.
So you can just create your initial $common structure in the main:: and then create threads, and each will get its own copy of it. Then threads can create their own SAFARI:: objects and do as they please with the data structure. A simple demo
use warnings;
use strict;
use feature 'say';
use Data::Dump qw(dd pp);
use threads;
my $ds = { val => 10, ra => [ 10..12 ] };
my #threads = map { async(\&proc_ds, $ds) } 1..3;
$_->join() for #threads;
say "main: ", pp $ds;
sub proc_ds {
my ($ds) = #_;
# Modify data in the thread
$ds->{val} += 10 * threads->tid;
$_ += $ds->{val} for #{$ds->{ra}};
say "Thread ", threads->tid, ": ", pp $ds;
}
This prints
Thread 1: { ra => [30, 31, 32], val => 20 }
Thread 2: { ra => [40, 41, 42], val => 30 }
Thread 3: { ra => [50, 51, 52], val => 40 }
main: { ra => [10, 11, 12], val => 10 }
If, instead, you need to share data structures perhaps see this page, for example.
Each thread then needs to use a class hierarchy, whereby multiple subclasses should be initialized the same way using a common data structure modified in each thread.†
In Perl's inheritance model, methods gets inherited from the parent class but not data. So the question here is how to nicely populate all subclasses to same data.
There are advanced techniques that may make the process more elegant, but I'd suggest to simply introduce the attribute and define the method in the parent class and then have all subclasses use it to initialize. That is going to be crystal clear, and as economical as anything else. Like
use SAFARI::View;
use SAFARI::Other;
# ... set/customize $common
my ($sview_obj, $sother_obj) =
map { $_->new->init_common($common) }
qw(SAFARI::View SAFARI::Other);
say "View object: $sview_obj"; # overload "" (quotes) for this, see below
This would be done in each thread, where $common is first customized per thread as needed.
There isn't a magical way for the derived classes to pick up data from the parent, and you don't want a base class to have to know about its derived classes, in principle. And there is nothing wrongjk with nicely instantiating all subclasses, much like in the question itself.
The sub init_common need only be defined in SAFARI, the parent class
SAFARI.pm file
package SAFARI;
use warnings;
use strict;
sub new {
my ($class, #args) = #_;
my $self = {
common => {}, # introduce the attribute, for clarity
# ...
};
return bless $self, $class;
}
sub init_common {
my ($self, $data) = #_;
$self->{common}->{dbh} = $data->{dbh}; # etc, populate common
return $self;
}
...
1;
We don't need to specify the attribute in the constructor if it's not being set as it will be created by writing to $self reference in init_common, but listing it helps clarity. (Of course, common attribute can be written at construction ‡ as well; and, we don't need a separate method for it either.)
Derived subclasses need not mention any of this, attribute nor init_common method, unless they should customize things.
SAFARI/View.pm file
package SAFARI::View;
use warnings;
use strict;
use feature 'say';
use Data::Dump qw(pp);
# Make sure #INC gets set as needed
use parent 'SAFARI';
use overload ( q("") => sub { return pp {%$_[0]} } );
# no need for init_common, nor for new (except to modify/override)
sub output {
my ($self, #args) = #_;
say $self->{common}->{...};
return $self;
};
...
1;
† Inheritance is already in place here, otherwise composition or roles would be good alternatives. Even so, still consider using a role here; see this post for instance.
‡ If 'common' data can be passed to the constructor
sub new {
my ($class, $attr) = #_; # pass a hashref with attribute => value
my $self = {
common => {}, # introduce the attribute, for clarity
# ...
};
bless $self, $class;
$self->init_common( $attr->{common} ) if exists $attr->{common};
return $self;
}
sub init_common {
my ($self, $data) = #_;
$self->{common}->{$_} = $data->{$_} for keys %$data;
return $self;
}
then 'common' can also be initialized as
# ... set/customize $common
my ($sview_obj, $sother_obj) =
map { $_->new( { common => $common } ) }
qw(SAFARI::View SAFARI::Other);