Shareable objects.

[BrowserUk]

This isn't much of a meditation. More of a, here's a possibility that I do not have the time to pursue, does anyone want to pick it up, play with, run with it or shoot it down in flames.

It would appear from the discussion and posts here that people want to share objects across threads. That currently isn't possible without extreme shenanigans because shared variables are implemented using tie magic. And blessing object references also uses magic. And you cannot apply the two types of magic to a single entity.

More or less. There maybe more to it than that, but it will take someone with a better understanding of the internals than I have to explain more.

There are existing solutions to this problem that involve creating proxy objects that communicate all the actions to a master object. The problem with this is that they are incredibly slow because every method call requires at least 2 task switches and usually more.

The basis of my proposed solution is a little known perl OO technique termed (by dominus) Globjects. Follow that link to read about them, I'll stick to how they permit the sharing of objects across threads here.

Globjects are basically blessed globs. As you may know, a glob is an internal container which can hold, amongst other things a scalar, an array and a hash. See broquaint's excellent description Of Symbol Tables and Globs for more on them.

By basing objects around a blessed glob, you can share the scalar, array or hash, (or all 3 if you wish), that the glob contains. And because the you don't need to share the glob itself, the glob can be passed around and cloned, whilst retaining is blessedness, and allow the methods called via the blessing magic, to access the shared elements it contains. And that is pretty much it.

To get anyone with the time and motivation going, here is my extremely simple and un-thorough proof of concept code:

#! perl -slw
package dummy;
use threads;
use threads::shared;

sub new{
    my $self = bless do{ local *GLOB; \*GLOB }, $_[0];
    share( %{ *$self } );
    %{ *$self } = qw[ there are some parameters here 1 ];
    $self;
}

sub get{
    my $self = shift;
    @{ *$self }{ @_ || sort keys %{ *$self }  } ;
}

sub put{
    my $self = shift;
    lock %{ *$self };
    ${ *$self }{ +shift } = shift while @_;
}

package main;
use strict;
use threads;
use threads::shared;

our $N ||= 10;

sub t{
    my $obj = shift;
    sleep 1;
    my $tid = threads->self->tid;
    warn "$tid: ", join'|', $obj->get(), $/;
    sleep rand 10;
    $obj->put( $tid, $tid );
    warn "$tid: ", join'|', $obj->get(), $/;
}

my $obj = new dummy;
print join '|', $obj->get;

my @t = map{ threads->create( \&t, $obj ) } 1 .. $N;

$_->join for @t;

print join '|', $obj->get;

__END__
c:\test>sglobjects.pl
1|parameters|are
1: 1|parameters|are|
2: 1|parameters|are|
3: 1|parameters|are|
3: 3|1|parameters|are|
4: 3|1|parameters|are|
5: 3|1|parameters|are|
6: 3|1|parameters|are|
7: 3|1|parameters|are|
8: 3|1|parameters|are|
9: 3|1|parameters|are|
10: 3|1|parameters|are|
1: 1|3|1|parameters|are|
7: 1|3|7|1|parameters|are|
4: 1|3|4|7|1|parameters|are|
9: 1|3|4|7|9|1|parameters|are|
2: 1|2|3|4|7|9|1|parameters|are|
5: 1|2|3|4|5|7|9|1|parameters|are|
6: 1|2|3|4|5|6|7|9|1|parameters|are|
10: 1|10|2|3|4|5|6|7|9|1|parameters|are|
8: 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

What that output shows is that all 10 threads are able to indirectly manipulate (via methods) the contents of the shared hash contained within the blessed glob. The same also works for the array and scalar it contains. And that's all it shows. Everything else, destruction, performance etc. needs testing and proving. Enjoy.

[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.

[BrowserUk]

As threads::shared provides its own bless() implementation,

Hm. And when did that happen?

From the threads::shared POD:

BUGS

bless is not supported on shared references. In the current version, bless will only bless the thread local reference and the blessing will not propagate to the other threads. This is expected to be implemented in a future version of Perl.

I guess I don't understand your problem statement ?

How about this this "problem statement", and this "problem statement", and oh, say two dozen more posts here that have asked for this or cited this restriction as a reason for not using iThreads?

[renodino]

As threads::shared provides its own bless() implementation,

Hm. And when did that happen?

From the threads::shared POD: ...

I don't know precisely when, but its in the code. You can go look it up yourself. Just grab threads::shared from CPAN, and open shared.xs in the editor of your choice. I'll leave it to you to do the backtracking to see when it showed up.

As to the bug, I believe it now refers only to passing a variable from thread A to thread B, wherein thread B bless()es it. Thread A's version won't get its proxy's stash updated, ergo, thread A doesn't know its been blessed. However, if thread B passes the object back to thread A, A will get a new blessed copy. IOW, when a new proxy instance of a shared variable is created, any blessing the "real" version has inside the shared interpretter is propagated to the new proxy. (Thats the reason for thread::shared's bless() override: to put the package in the shared interpretter's stash). But since the thread that's blessing doesn't know anything about the other thread's existance, much less having direct access to its private interpretter, the new blessing can't be propagated. Presumably, a solution could be provided that would check a variable's shared interpretter stash and keep it in sync with private proxy versions on every access...but threads::shared has enough performance issues in that regard wo/ piling on something thats likely very rare, and can probably be worked around.

The only other issue I'm aware of is if thread A creates an object from a package that it "require"s internally, but which is not require'd in a thread to which the object is passed. In that instance, the receiving thread doesn't have the package info in its thread-private interpretter, and so it chokes on any object references.

Well, and maybe the inconvenience that any refs assigned to shared object members must themselves be shared. But thats a general groundrule, not unique to shared objects.

As to the provided links, I'll can only state that I haven't time at the moment to follow every thread on perlmonks to their final conclusion.

Perhaps the threads::shared docs need some clarification, and the blessing of shared objects needs to be evangelized better ?

[goibhniu]

I've lost score here. It seems to me BrowserUK has a good way to do shared objects across threads, despite the fact that threads::shared also has one. Doesn't this constitute an OWTDI? Shouldn't BrowserUK's method still be worked out for best practices and investigated for other effets and possible performance advantages? Perhaps this is a method that Threads::Shared itself might use to fix that last bug that renodino referred to.

I tried to read Globjects and Of Symbol Tables and Globs, but they were a little beyond me; if I had understood everything I read I would volunteer. If someone else picks this up and thinks I can help, let me know.