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

My gut feeling is that perl 5's threading model is probably the best possible, given all the constraints (i.e. backward compatibility).

The problem with it, as far as I can see, is that the API is quite terrible (especially the perl side of things; it's probably easier to write complex pieces of a threaded perl application in C/C++). My main problem with it is that there is no common way of creating shared/shareable, object oriented libraries.

"What should it profit a man, if he should win a flame war, yet lose his cool?"
  • Comment on Re^4: Slow evolution of Perl = Perl is a closed Word (thread decade)

Replies are listed 'Best First'.
Re^5: Slow evolution of Perl = Perl is a closed Word (thread decade)
by BrowserUk (Patriarch) on Sep 03, 2007 at 21:53 UTC
    My main problem with it is that there is no common way of creating shared/shareable, object oriented libraries.

    Two questions to ponder:

    1. Why is sharing objects in perl verbotten?
    2. What could be done to alleviate that restriction?

    If I told you that there is a simple mechanism that allows most form of perl OO to work as shared objects, without imposing the high cost of proxy object solutions, would you be interested?

    Would it change your mind about the efficacy of threading in Perl 5?

    Or would some other reason to dislike them come to the fore?

    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]
      1) It's not verboten, but for instance, there is no idiom (yet) to do something like 
      $object->share;

      [download]
      And how to use threads in complex structures. In other words, I'm not complaining about the implementation, or even the general idea. I'm complaining about the (lack of) API. It seems to me that the "no sharing" principle is a good one, but it opens up a whole new set of problems that haven't yet been sufficiently addressed. See threads, refcounting, XS, DESTROY an for example, and note the last comment and the discussion linked in that comment.

      2) There should be a simple way of creating objects that either can be shared, or are shared by default. Having to explicitly share each and every member is just a pain in the ass.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
[d/l]
        See threads, refcounting, XS, DESTROY an example, and note the last comment and the discussion linked in that comment.

        Yes. I saw that. But there is more than one way to skin a cat.

        There should be a simple way of creating objects that either can be shared, or are shared by default. Having to explicitly share each and every member is just a pain in the ass.

        That is exactly what I am suggesting is possible. But you won't find the method documented anywhere, nor any example code that uses it. At least, none that I have been able to find. And as yet, I haven't had the opportunity to test it thoroughly to discover the caveats--if any.

        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