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

What you discussed here is not exactly what BrowserUK mentioned. As he is one of those who has contributed lots here to the threading topic, be default, I trust that when he said thread, he really meant thread, not fork or child processes.

I like the content of your node, no dount about that, but I think it is worth to clarify that you didn't strictly stay on the same subject as his.

  • Comment on Re: Re: Re: latest on ithreads vs forks?

Replies are listed 'Best First'.
Re: Re: Re: Re: latest on ithreads vs forks?
by perrin (Chancellor) on May 27, 2004 at 03:24 UTC
    On the contrary, I'd say both of these posts are discussing memory use by Perl threads and how it compares to forking. Forking benefits from copy-on-write, while threads do not, meaning that forking tends to use much less memory. This also means that the approach for conserving memory as much as possible is exactly the opposite in each one: load as late as possible for threads and as early as possible for forking.
[reply]
Re: Re: Re: Re: latest on ithreads vs forks?
by etcshadow (Priest) on May 27, 2004 at 03:44 UTC
    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

    [download]
[reply]
[d/l]
      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

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

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom