Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: Slow evolution of Perl = Perl is a closed Word

by chromatic (Archbishop)
on Sep 01, 2007 at 06:28 UTC ( [id://636488]=note: print w/replies, xml ) Need Help??


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

How many years we will need to wait...

I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl. Things don't get done unless someone does them. Sometimes that means people that want them have to take some initiative in getting them done.

Replies are listed 'Best First'.
Re^4: Slow evolution of Perl = Perl is a closed Word
by BrowserUk (Patriarch) on Sep 01, 2007 at 07:24 UTC
    I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl.

    The first step in achieving a good threading model is understanding the limitations of the existing one.

    And the first few steps in doing that is realising that:

    1. the pthreads api has its own set of limitations and is far too low-level to use as the basis for threading in a HLL.
    2. fork is a piss poor model for threading.
    3. Copy On Write (COW) has little or no benefit when the C-level data structures representing Perl-level read-only variables are themselves routinely, internally mutated.
    4. for threading to be fully effective in a high level language, you need both kernel-space (pre-emptive) threading and user-space (cooperative) threading.
    5. Software Transaction Memory (STM) only works for undoable (re-startable) operations.

      If STM is the only state-sharing mechanism, then a very high proportion of the situations and algorithms that most benefit from threading can no longer be coded!

      • You can't undo changes to the file-system, so copy, move, rename, delete etc.

        Whilst it is conceivable to wrap these FS primitives such that they might be undone if the STM requires rollback, other processes may have noticed and acted upon the changes

      • You might attempt buffering reads and writes to files internally, until the STM commits?
      • What do you do for pipe and socket operations?

      STM promises an efficient solution to shared-state memory operations which can benefit some classes of algorithm (the kinds of things PDL does for instance), but it holds little promise for a huge range of other threading scenarios.

    Did you ever visit one of those Echo Canyons, yell, and wonder if anyone is listening?

    Did you ever stick your head into a lion's cage to try and pursuade it to become a vegetarian?


    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.
      Did you ever visit one of those Echo Canyons, yell, and wonder if anyone is listening?

      Funny; as I type this, I'm running Parrot's language tests just before a checkin of working code. Now it's not threading code per se, but it's working code.

        Funny; as I type this, I'm running Parrot's language tests just before a checkin of working code.

        Really. That's great. I'm not sure how Parrot relates to what I've said in this thread? Nor even to anything I've ever said about Parrot?

        Now it's not threading code per se, but it's working code.

        But then again...if it is possible to create Parrot code, but not to create a thread to run that Parrot code, then could that be an indication that threads on Parrot is going to be another tack-it-on-later solution?

        To the -- wielder: feel free to kneejerk again on this thread. It won't change the significance or truth of the post, but you'll feel better.


        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.
Re^4: Slow evolution of Perl = Perl is a closed Word
by spx2 (Deacon) on May 07, 2009 at 16:49 UTC

    I disagree , some people don't have nearly enough knowledge to implement threads into Perl , telling anyone who wants threads that they should simply implement them is rather dangerous and possibly disastrous(considering that person may not be an expert on the subject , and maybe some people want to write industrial-strength code using Perl threads and don't need amateurish implementations of them ).

    From another point of view , many people just want to use threads , they don't need to implement them for that , they just want to USE them. It's a basic language feature for any decent language ( yes we're in 2009 ) and it's only normal to expect that Perl should have them . It seems most of the times , this is countered by an argument of the form "you don't really need threads, use POE" , which is ok , but that was not was asked in the first place .

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://636488]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2024-03-19 10:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found