flogic has asked for the wisdom of the Perl Monks concerning the following question:

I'm working on a large Perl progam using POE, Tk, and some large data structures. Since I'm stuck waiting on things that will block and don't want to play nice with the event loop, I figured using threads might save me some trouble. To get around copying of everything when ever a thread is spawned. I kick off a speical initiator thread at the begining to spawn the new threads whenever I need them. The initiator starts up in a reasonable period of time. However whenever the initiator starts up a new thread it takes a long period of time. I would think it would be fairly fast since the initiator doesn't have the baggage of the main thread. Any ideas why I'm wrong?

Replies are listed 'Best First'.
Re: Cheating heavyweight threads
by BrowserUk (Patriarch) on Aug 02, 2004 at 20:42 UTC

    POE and threads? Interesting concept. I don;t know of any reason it wouldn;t work, but I've barely scratched the surface of POE. I don;t really see the need for it once you have threads...but maybe I missing the point.

    Anyway. I think that the golden rule with iThreads is "Don't spawn-on-demand: Pool!".

    Do you have a testcase?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

      POE seems to help for managing the communcation between threads. Especially for my main thread which is primarily a Tk gui app and the child threads are just there to keep things reponsive.

      I don't have a test case but it may not be a big deal to make one.

        If a testcase that demonstrated the slow spawning of threads that you queried, was available, it might be possible for people to see ways of helping you solve it, or determine that there is a bug and report it.

        The situation you describe has a complex set of components and timings. Attempting to reproduce such a scenario blind would be guesswork.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
Re: Cheating heavyweight threads
by hardburn (Abbot) on Aug 02, 2004 at 20:35 UTC

    Are you using threads in the 5.8 series? If so, don't. They're too buggy for practical use.

    To get around copying of everything when ever a thread is spawned. I kick off a speical initiator thread at the begining to spawn the new threads whenever I need them.

    Most modern systems support Copy On Write (COW), meaning the two threads will defer copying the data until a thread tries to write to it. Also, forking a new process is cheep under Linux, though YMMV on other systems.

    ----
    send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

      I think you need to say either more or less than that.
        I don't get it, great point! =)


        -Waswas
Re: Cheating heavyweight threads
by ysth (Canon) on Aug 02, 2004 at 23:43 UTC
    This might be an incidence of perl bug #29637, fixed in perl5.8.5.
Re: Cheating heavyweight threads
by borisz (Canon) on Aug 02, 2004 at 22:57 UTC
    I would not recommend to use threads ( both 5005 and ithreads ) in real applications. They are just to buggy. Your application will crash from time to time without reason. Do it the old way with fork and pipes for production.
    Boris

      Not since 5.8.4 they don't ... unless you have some evidence to the contrary?.. this is just FUD!


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon