Actually, sharing a simple scalar does keep its value:
use threads; use threads::shared; my $foo = "foo\n"; share( $foo ); print $foo; __END__ foo
Internally, share() is basically a tie on the reference of what is specified. This is the same approach I use with forks: oddly enough, forks doesn't have that problem, e.g. with a hash:
I think I'll keep this "inconsistency" in forks, but will add a little note in the pod about this. I agree this is a bug in threads::shared that should be fixed. As always, patches are welcome ;-)use forks; use forks::shared; my %foo = (bar => "foo\n"); share( %foo ); print %foo; __END barfoo
...These and other things might have been useful to put the threads::shared docs...
Please feel free to supply a documentation patch to p5p, or a proposal for (additional) text here (in which case I'll turn it into a documentation patch and submit it to p5p on your behalf).
...it seems I can cheat a little, use freeze/thaw, and actually share objects...
FWIW, that's the approach that Thread::Queue::Any, Thread::Conveyor and Thread::Tie use under the hood (which is actually externalized into its own module: Thread::Serialize).
...Anyone know how, what, why and WTF?
Look at shared.xs in your Perl distribution. I think most of the problem comes from the fact that there is internally only 1 subclass for the tieing: threads::shared::tie. Whereas in forks, I have taken the approach of creating a seperate subclass for each data type.
Hope this helps.
Liz
In reply to Re: ithreads, shared variables..
by liz
in thread ithreads, shared variables..
by castaway
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |