in reply to Re^9: Slow evolution of Perl = Perl is a closed Word (thread decade)
in thread Slow evolution of Perl = Perl is a closed Word

For the former, I've yet to see a convincing application for shared objects. Do you have one?
I have more than once wanted a cache of objects, sharable between threads. Because there's no such beast, the cache ends up living in some external storage and the objects are unmarshalled/marshalled for each access.
  • Comment on Re^10: Slow evolution of Perl = Perl is a closed Word (thread decade)

Replies are listed 'Best First'.
Re^11: Slow evolution of Perl = Perl is a closed Word (thread decade)
by BrowserUk (Patriarch) on Sep 04, 2007 at 09:19 UTC
    I have more than once wanted a cache of objects, sharable between threads.

    Sorry ysth, but that isn't an application. It's one solution to an unstated problem. Given it's you, it's probably a perfectly reasonable solution to it, but on it's own, "wanting shareable objects" is not a convincing argument for having shareable objects.

    And would whomever downvoted this post care to explain themselves? Of course not. That would require difficult stuff like thought and reason.

    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.
[reply]
      I was a bit terse. The "cache" was the application part. Given hard to construct objects (say, involving multiple database queries, or even user input), saving them to be reused rather than discarding and rebuilding as needed, in a situation where separate caches for each thread/process would either not be worthwhile or would be too memory consumptive.
[reply]
        I was a bit terse. The "cache" was the application part.

        Okay. I didn't see that interpretation.

        My first reaction is: whatever thread is responsible for the construction/generation of the objects that you want to cache, caches them.

        Ie. If you have a DB thread that is issuing queryies and retrieving results on behalf of all the other threads in the application, then it does the caching. If any thread asks for the same data, (presumably via a queue), then it replies with the results from its local cache.

        Ditto for user input. You have a single thread dealing with user input and when another thread requests input it is supplied from the input thread local cache if available.

        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.
[reply]

In Section Meditations