in reply to unable to store shared hash with Storable

This is one of those occasions when the intelligence in one module (Storable) combines with the incompleteness of another (threads::shared), to produce a mess.

Your JSON cloning mechanism is overkill though. A simple dumb clone() does the trick:

#! perl -slw use strict; use Data::Dump qw[ pp ]; $Data::Dump::WIDTH = 1000; use threads; use threads::shared; use Storable qw[ store retrieve ]; sub clone { my $ref = shift; ref( $ref ) or return $ref; ref( $ref ) eq 'SCALAR' and return \(''.$$ref); ref( $ref ) eq 'HASH' and return { map+( $_, clone( $ref->{$_} )), keys %{ $ref } } +; ref( $ref ) eq 'ARRAY' and return [ map clone( $ref->[$_] ) , 0 .. $#{ $ref } ] +; die; } my %hash : shared = ( letters => shared_clone( { 'a'..'z' } ), numbers => shared_clone( { 1 .. 100 } ), ); store clone( \%hash ), "$0.bin"; my $retrieved :shared = shared_clone( retrieve "$0.bin" ); pp $retrieved;

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.

Replies are listed 'Best First'.
Re^2: unable to store shared hash with Storable
by traceyfreitas (Sexton) on Aug 11, 2011 at 18:48 UTC

    Awesome. I benchmarked both the JSON and your clone() sub on one of my actual datasets -- with store() -- and both obviously worked really fast:

    CLONE() TIME: 0 wallclock secs ( 0.18 usr + 0.00 sys = 0.18 CPU) JSON TIME: 0 wallclock secs ( 0.16 usr + 0.00 sys = 0.16 CPU)

    There are only very slight size differences in the binary files produced by store():

    624924 Aug 11 12:39 sharedhash.json 622808 Aug 11 12:39 sharedhash.clone
    but they still contain the same data when "retrieved". Thanks, BrowserUK.