in reply to threads: spawn early to avoid the crush.

Have you looked at Thread::Isolate?
It might just be what you need, since it creates a so-called "mother thread" that should hold a cleaner state of the perl interpreter.


acid06
perl -e "print pack('h*', 16369646), scalar reverse $="
  • Comment on Re: threads: spawn early to avoid the crush.

Replies are listed 'Best First'.
Re^2: threads: spawn early to avoid the crush.
by BrowserUk (Patriarch) on Mar 03, 2006 at 02:38 UTC

    Yes, but any solution that uses string eval means that you lose all the compile-time checking of the code contained in the strings(*), as well as being extremely slow if you call the code more than once.

    For example, if you wish to spawn a thread to handle client connects, the time spent re-evaling the code to run in the thread, will leave your main thread unresponsive to accept new connections for too long.

    And when things go wrong in your threads, you are left with no clues as to what and where.

    It also uses Storable freeze/thaw combinations to pass data to/from/between threads. This is even slower than shared data; doesn't handle large volumes well; and makes assumptions about what the data will contain.

    I admire gmpassos greatly for the attempt, but it doesn't really work well in use.

    (*) IMO, a much better reason for avoiding string eval than "security issues".


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.