in reply to Re^4: choosing threads
in thread choosing threads

That is why I have decided to go for threads. because I thought that in fork I might waste some time in creation of process and resources associated with that, so i decided to go for threads, since they are lightweight compared to fork.

If that's your only reason for considering threads for this, use fork instead. Perl's threads are not lightweight.


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^6: choosing threads
by targetsmart (Curate) on May 11, 2009 at 09:04 UTC
    Please enlighten me; why perl threads are not lightweight?.

    Vivek
    -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.

      Because, whereas in a compiled langauge each thread consists of little more than a set of cpu registers, a stack and an entry in the system scheduler tables; in Perl, you need those: plus a complete interpreter, plus per-interpreter copies of all non-entrant state.

      And as Perl began life as a single-threaded app, its internal state and control structures were never designed from the outset to be reentrant, which means there is of necessity, large volumes of per-thread duplication.


      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.