http://qs321.pair.com?node_id=426379


in reply to Isolating dynamically loaded modules with Thread::Isolate.

The simpler answer is to use processes instead of threads. On Linux and other unixy OSes, you can fork multiple processes and most of the memory will be shared by the OS using copy-on-write. Perl threads don't do that, so they use much more memory.
  • Comment on Re: Isolating dynamically loaded modules with Thread::Isolate.

Replies are listed 'Best First'.
Re^2: Isolating dynamically loaded modules with Thread::Isolate.
by samtregar (Abbot) on Jan 30, 2005 at 19:16 UTC
    Preach it.

    It's completely mystifying to me that people are using Perl threads for real work on UNIX systems. Much of the promise of threads - lower memory footprint, faster spawn and join, easier management - are absent from Perl's implementation. All that's left is easier communication between tasks which doesn't seem like much of a gain compared to the drawbacks.

    -sam

      I you don't need inter-task communications, then I agree, but the biggest problem people have with using threads is trying to use them in the same way that forks are used. This is true of whether using iThreads or pthreads, or most other forms of threading.

      Just as Perl requires the adoption of a different way of working to C if you are to realise the best from it, so once you have relatively easy inter-task communications, a different way of working and thinking is called for.

      And there are other platforms than the unix-like world.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.

        IPC is weakness of multiprocess models, and I'm disappointed that everyone has been content to stick to the same IPC mechanisms which have been around since day one. I'd rather prefer if the amount of effort that has gone into threads in the Unix world at large had gone into making it easier for forked processes to communicate when they need to. A highlevel language like Perl where variables are more than just names for memory locations offers particularly great opportunities to hide much of the drudgework of IPC from the programmer.

        Defaulting to no shared memory is inherently safer than defaulting to all memory being shared, and on modern CPUs with useful MMUs forking doesn't even cost a single extra cycle. Threads are implemented in terms of fork() in the Linux kernel.

        Threads are mainly useful as a way to regain some of the fork() semantics on amputated platforms that don't natively offer something equivalent. Indeed, the iThreads you so like, in various respects behave more like forked processes than like ye olde threads.

        Makeshifts last the longest.

        I you don't need inter-task communications, then I agree, but the biggest problem people have with using threads is trying to use them in the same way that forks are used. This is true of whether using iThreads or pthreads, or most other forms of threading.

        Frankly, my biggest problem with using threads in Perl is that the implementation isn't very good. It's slow, uses a ton of memory and has some very non-intuitive restrictions. It feels exactly like what it is - a second-rate feature added as an after-thought.

        -sam

      I consider the easier communication to actually be a drawback of threads. More opportunities for accidental race conditions!
      A reply falls below the community's threshold of quality. You may see it by logging in.