in reply to Why use threads over processes, or why use processes over threads?

Creating a new process can be expensive.

Just for kicks, read the code required to create a new thread in Perl. Any operating system that can't launch a new process more quickly than Perl can launch a new thread is severely broken.

If you like threads better, that's fine, but this line of reasoning doesn't hold much water. You're probably going to hit the kernel when creating a thread — you need things like memory, at some point. You're going to hit the scheduler, at some point, at least with system threads. (Of course, that's not what Perl has.)

Throwing out handwavy performance arguments altogether, your arguments are:

I'd also add that sharing data between threads tends to be nicer than messing with shared memory portably, mostly because Unix shared memory never really made sense to me. That, to me, is a compelling reason. I mostly ignore the others.

  • Comment on Re: Why use threads over processes, or why use processes over threads?

Replies are listed 'Best First'.
Re: Re: Why use threads over processes, or why use processes over threads?
by petesmiley (Friar) on Nov 11, 2003 at 16:53 UTC
    ++ This is very accurate for me as well. I've done a bit fork programming and a bit of thread programming. Sharing data with forks has always struck me as "funky".

    I have another good reason to use threads. According to the threads doc, fork under windows is a hack using threads. Many of my programs run on Windows. I believe this sometimes led to "funky" (seemingly unforkish) behavior when I tried to use forks.

    As listed in the threads doc:

    Prior to perl 5.8 this has only been available to people embedding perl and for emulating fork() on windows.

    So I pretty much just use threads now when I program for something that will run under windows. Thankfully, the memory leaks are being weeded out :) It would be really nice to get the best out of both worlds with threads, but I suppose it will just take time to polish it.

    smiles

[reply]
Re: Re: Why use threads over processes, or why use processes over threads?
by hardburn (Abbot) on Nov 11, 2003 at 15:17 UTC

    Just for kicks, read the code required to create a new thread in Perl. Any operating system that can't launch a new process more quickly than Perl can launch a new thread is severely broken.

    Is that a consequence of implementation, or is it a real design flaw in Perl's threading code? I really don't know enough about threading implementation to know, but I suspect this is a problem that is fixable in future versions.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]

      That's a consequence of implementation. Creating a new thread means cloning a Perl interpreter. That requires a lot of work. That's where something like Thread::Pool is handy; you still pay the price for launching threads, but you do it at startup.

[reply]
Re: Re: Why use threads over processes, or why use processes over threads?
by tbone1 (Monsignor) on Nov 12, 2003 at 12:58 UTC

      I'd also add that sharing data between threads tends to be nicer than messing with shared memory portably, mostly because Unix shared memory never really made sense to me.
    Personally, I was never impressed with it on VMS. On Unix it's an absolute dream in comparison. (At least this is what my unreliable synapses are telling me.)

    Shared memory is not perfect (what is, come to that), but it allowed me on one project, years ago, to share "live, up-to-date" data between users at twelve different sites, and did so in a reliable, relatively stable way. I've not done much with threading, so my view may be prejudiced, but you would have to prove to me that threading would be a better solution on such a situation. I'd listen, but I'd listen with a cynical ear.

    --
    tbone1
    Ain't enough 'O's in 'stoopid' to describe that guy.
    - Dave "the King" Wilson

[reply]

In Section Meditations