in reply to Re^2: Slow evolution of Perl = Perl is a closed Word
in thread Slow evolution of Perl = Perl is a closed Word

5 years? People have been trying to get decent threading into Perl at least twice that long. Bolting threading onto the side of a language that was developed in a way that is rather antithetical to threading is an extremely ugly task. I doubt you'll ever see reasonable threading in Perl 5 because

  1. I haven't seen over that decade the will to initiate the rather fundamental rewrite that would be required
  2. Perl 6 makes such a fundamental rewrite within Perl 5 even less likely

A decent threading model was attempted for many years and eventually abandoned as impossible and replaced by a horrid threading model that had a better hope of one day becoming stable, if no hope of ever becoming a particularly good way of doing threading.

So the hope for decent thread support in Perl is simply Perl 6.

- tye        

  • Comment on Re^3: Slow evolution of Perl = Perl is a closed Word (thread decade)

Replies are listed 'Best First'.
Re^4: Slow evolution of Perl = Perl is a closed Word (thread decade)
by Joost (Canon) on Sep 03, 2007 at 21:38 UTC
    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?"
[reply]
      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]

In Section Meditations