in reply to Re: Bad nstore of a shared hash
in thread Bad nstore of a shared hash

Let me see if I got it right. You use async just to get a copy of the hash? You don't really need that fork, right?

Also, how is that the copy created is not shared also?

Replies are listed 'Best First'.
Re^3: Bad nstore of a shared hash
by BrowserUk (Patriarch) on Sep 21, 2010 at 23:36 UTC
    You use async just to get a copy of the hash?

    No. I used the async to demonstrate Storable work fine within threads; that the problem you encountered is with threads::shared::tie.

    So yes, the threading was unnecessary to demonstrate that Storable works, but we know that already ;)

    Also, how is that the copy created is not shared also?

    Because nothing is shared unless you explicitly share it.

    The reference to the shared hash %hash, simply results in a list of values. Placing them inside an anonymous hash constructor, constructs a thread-local (ie.non-shared), anonymous hash. Which Storable can nstore() in the usual way.

    It is effectively the same as just: nstore { 1, 'a', 2, 'b }, 'fred.bin';. Except that the values come from a shared hash rather than constants.


    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.
      Thanks!