in reply to Re: Re: Re: latest on ithreads vs forks?
in thread latest on ithreads vs forks?

Ah, brain-fart. He did say "in threads". It just goes to show that I come from a very process/fork intensive world (work a lot with apache 1.X which is all about processes and forks... likewise older perl (5.005_03) wherein threads were not really 100%).

So I guess I was a little off-topic with my reply. Doesn't make it not true, though :-)

Honestly, I didn't reallize that threads did not use shared memory. If anything, I'd have assumed that they used shared memory even more than processes. After all, in threads, the semantic is not copy-on-write... it's syncronize-on-write (so if it were just shared to begin with, there'd be no need to copy the data between threads' memory pages... just syncronize access when performing writes). But, anyway, as I said: I'm no thread-head. (Understand the concepts but very little actual experience with using them or the details of their implementations.)

------------ :Wq Not an editor command: Wq

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: latest on ithreads vs forks?
by liz (Monsignor) on May 29, 2004 at 09:48 UTC
    Honestly, I didn't reallize that threads did not use shared memory. If anything, I'd have assumed that they used shared memory even more than processes. After all, in threads, the semantic is not copy-on-write...

    But Perl threads are different. ;-(

    Liz

      That's very interesting. I have to admit that I'm still stuck in the perl 5.005 world (with plans to upgrade later this year). So my knowledge of perl threads come from the 5.005 threads documentation (as I said elsewhere... only from documentation, not from using them). And that documentation paints a very different picture. Wow.

      In short, the fact that (more recent) perl's threads are implemented neither as lightweight processes (kernel threads) nor with non-shared data as forked copy-on-write memory, just floors me. I hate to be overly critical of the folks who have given me so much... espescially without understanding what the detailed rationale for this kind of approach was... But still: what the heck?

      Well, I can at least hope that what they've really done is define an interface that they can work with, over a somewhat defficient implementation, with plans to go back and improve the implementation while preserving the interface. I've got to say that the amount of churn in the threading implementation of perl has got to be a set-back for its acceptance, at this point.

      ------------ :Wq Not an editor command: Wq