Re: Shareable objects.

[renodino]

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

1. support legacy, possibly threads-hostile modules (e.g., DBI => DBIx::Threaded, Tk => Tk::Threaded, etc.)
2. 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"¹) 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.