in reply to Re^2: Sharing large data structures between threads
in thread Sharing large data structures between threads

I would suggests that the requests, if you pursue that idea, “should merely be descriptive.”   If the manner by which they are (presently...) implemented is by very-clever use of eval, then so be it ... but don’t scatter that implementation detail throughout all of the client code.   One day, you might decide that this approach is not so Tom Swifty after all, and if this be so, it should be easily and (ahem...) “Swiftly” replaceable without impacting much source-code that is hither, tither and yon.

Replies are listed 'Best First'.
Re^4: Sharing large data structures between threads
by anonymized user 468275 (Curate) on Mar 09, 2011 at 17:32 UTC
    Yes, I agree. In practice, I would create a package with a trivial new, and insert, update, delete and fetch methods as a generic interface which could be replaced by alternative solutions at a later time transparently to the caller(s).

    One world, one people

      I would create a package with a trivial new, and insert, update, delete and fetch methods as a generic interface

      And all you would have done is replicate the tie mechanism with slightly different method names and calling syntax. It would be no more efficient of time nor space. No easier to use or maintain.

      And it would need to address all the same locking and sharing, creation and destruction problems that thread::shared variables already address.


      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.
        Actually, it converts the asynchronous commands from the threads or forks into a single synchronous stream. This mimicks an early IBM-mainframe style solution to transaction processing from way back.

        One world, one people