Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: Isolating dynamically loaded modules with Thread::Isolate.

by samtregar (Abbot)
on Jan 30, 2005 at 19:16 UTC ( #426409=note: print w/replies, xml ) Need Help??


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

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

  • Comment on Re^2: Isolating dynamically loaded modules with Thread::Isolate.

Replies are listed 'Best First'.
Re^3: Isolating dynamically loaded modules with Thread::Isolate.
by BrowserUk (Pope) on Jan 30, 2005 at 19:31 UTC

    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.

        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.

        Aristotle Quit doggin' me.

        A platform that chose a non-forking model of multi-tasking isn't "amputated", it just made different--I would contend, more modern and sensible; but don't let's get into that argument-- design-time choices.

        The biggest single problem with iThreads is that they attempt to emulated that model of operation.

        I simply try to make best use of what is available, and counter the (ongoing) FUD that they are unusable. And I think that I have demonstrated conclusively that used properly, they can be used very effectively.


        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
      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

        It's slow, uses a ton of memory

        The following code spawns 100 threads in under 2 seconds and uses < 40MB?

        >perl -Mthreads -le"print time;@t=map{threads->new(sub{sleep 300})}1.. +100;print time;<>" 1107144770 1107144772

        I agree they aren't doing much, and that is probably considerably slower than you can spawn 100 processes--but if you need the parent to communicate with the children and vice versa, then you'd need to a lot more work using fork.

        It is true that there are some inconvenient restrictions (some of which could be alleviated), and you do have to learn a few simple techniques for getting the best from them--like not loading anything you don't want shared before you spawn your threads--but they are stable and very usable.

        On Win32, they are infinitely preferable to fork, but I realise that that is a restriction of the platform. I can well see why anyone on unix wouldn't bother with them unless they really needed bi-directional communications.

        I agree that the implementation is imperfect, but having spent a little time looking into the work that they are doign, I think teh guys that got them to where they are are did an brillaint job given the task they faced.


        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
Re^3: Isolating dynamically loaded modules with Thread::Isolate.
by tilly (Archbishop) on Jan 31, 2005 at 03:05 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://426409]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2021-04-13 13:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?