I guess I don't understand your problem statement ?
As threads::shared provides its own bless() implementation,
it is certainly quite possible to bless shared variables.
Here's an updated version of your example using stock
threads::shared and a regular hashref object. It adds
a wrinkle in order to more thoroughly test a perceived
limitation: rather than creating the shared object prior
to spawning threads - which will automatically clone the
shared object into all threads -, this example creates
the object after the threads are spawned, and passes
the object to each thread via a Thread::Queue:
package dummy;
use threads;
use threads::shared;
use strict;
use warnings;
sub new{
my %self : shared = qw[ there are some parameters here 1 ];
return bless \%self, $_[0];
}
sub get{
my $self = shift;
@{ %$self }{ @_ || sort keys %$self } ;
}
sub put{
my $self = shift;
lock %$self;
$self->{ +shift } = shift
while @_;
}
package main;
use threads;
use threads::shared;
use Thread::Queue;
use strict;
use warnings;
our $N ||= 10;
sub t {
my ($q) = @_;
my $tid = threads->self->tid;
my $obj = $q->dequeue();
sleep 1;
warn "$tid: ", join'|', $obj->get(), $/;
sleep rand 10;
$obj->put( $tid, $tid );
warn "$tid: ", join'|', $obj->get(), $/;
}
my $q = Thread::Queue->new();
my @t = map{ threads->create( \&t, $q ) } 1 .. $N;
my $obj = new dummy;
print join '|', $obj->get, $/;
$q->enqueue( $obj ) for @t;
$_->join for @t;
print join '|', $obj->get;
_END_
C:\Perl>perl globthrd.pl
1|parameters|are|
1: 1|parameters|are|
2: 1|parameters|are|
3: 1|parameters|are|
4: 1|parameters|are|
5: 1|parameters|are|
6: 1|parameters|are|
7: 1|parameters|are|
8: 1|parameters|are|
9: 1|parameters|are|
10: 1|parameters|are|
3: 3|1|parameters|are|
1: 1|3|1|parameters|are|
4: 1|3|4|1|parameters|are|
8: 1|3|4|8|1|parameters|are|
9: 1|3|4|8|9|1|parameters|are|
5: 1|3|4|5|8|9|1|parameters|are|
7: 1|3|4|5|7|8|9|1|parameters|are|
10: 1|10|3|4|5|7|8|9|1|parameters|are|
2: 1|10|2|3|4|5|7|8|9|1|parameters|are|
6: 1|10|2|3|4|5|6|7|8|9|1|parameters|are|
1|10|2|3|4|5|6|7|8|9|1|parameters|are
As to the reasons for using the master/proxy (
aka apartment threaded)
architecture, that isn't really about the ability (or not) of passing blessed
shared objects around, but rather, a way to
- support legacy, possibly threads-hostile modules (e.g.,
DBI => DBIx::Threaded, Tk => Tk::Threaded, etc.)
- simplify the mapping of concurrency onto component-oriented architectures,
thereby reducing/eliminating the need for component authors to get distracted
by tangential complexities (e.g., maintaining state machines), possibly
resulting in nicely shared-nothing architectures.
Indeed, in complex apps, both shared objects (as "resources"
1)
and apartment threaded objects (as "actors") are often needed.
Perhaps you could more precisely explain the problem you're trying to solve ?
Update:
One other (esoteric) differentiator for apartment threading vs. threads::shared objects:
the objects inside apartment threads don't need to be threads::shared, which means they access their members directly wo/ any locking (explicit or implicit). threads::shared objects have to navigate the "dead whale" (aka the global shared interpretter lock) for every member access...which may often (usually?) mean that they're going to take that context switch hit anyway...and possibly far more frequently than the apartment threaded alternative. So, in moderately threaded applications, the performance difference may be negligible.
1. Some will argue that resources can/should also be apartment threaded
in container objects to preserve shared-nothingness.
Perl Contrarian & SQL fanboy
