Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^3: Shareable objects. (Updated)

by renodino (Curate)
on Sep 05, 2007 at 17:04 UTC ( #637209=note: print w/replies, xml ) Need Help??

in reply to Re^2: Shareable objects. (Updated)
in thread Shareable objects.

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 ?

Perl Contrarian & SQL fanboy

Replies are listed 'Best First'.
Re^4: Shareable objects. (Updated)
by BrowserUk (Pope) on Sep 05, 2007 at 17:45 UTC
    Just grab threads::shared from CPAN,

    I already had it, and your code worked without me doing anything. But I woudl never had thought to try it because I knew it didn't work. I tried many times a long time ago. 'sides, the docs told me ot wouldn't

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

    If two of the most informed monks here didn't know about it, and if I, who may know nothing but do read anything and everything I see regarding threads, hadn't seen a single reference to it, then a little mention somewhere would be good thing I think :)

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://637209]
[SuicideJunkie]: Better not let those anti-Germans meet real Germans. Their heads would explode.
[LanX]: they are Germans ... no joke

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (15)
As of 2018-03-19 13:54 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (240 votes). Check out past polls.