I was never a fork man. The model followed by POSIX threads seemed a lot more natural (unlike the analogies that follow :).

With a thread, your program becomes like a person split in two. Both of you exist in the same universe at the same time. Both of you are free to walk around the room and fiddle with things you find. If your alter ego(s) are fiddling at the same time though, you might break something. You can even take an axe to your alter ego {1}, and the results are well defined.

Fork on the other hand is something like the many-universes theory of QM. There exists another copy of your self somewhere, but to talk to it you need to have an inter-dimensional pipe, and you need some machinery on either end to interpret and act on the messages. You can break less stuff, but you've got this big machine sitting in your living room ...

Anyhow, enough strained metaphor - what I want to know is, "to thread or not to thread", and why? I am frightened by the Camel book's sternly worded warnings, and the apparently hideous platform incompatibilities that might be introduced by adopting threads. Fork on the other hand seems to fit the perl world a lot more nicely.

Thoughts? Are you using the threading model, and has it died yet?

{1} Petruchio - yes I was thinking of the old money lender.

--
Ash OS durbatulk, ash OS gimbatul,
Ash OS thrakatulk, agh burzum-ishi krimpatul!
Uzg-Microsoft-ishi amal fauthut burguuli.

Replies are listed 'Best First'.
Re: To thread or not to thread
by jepri (Parson) on May 30, 2002 at 06:49 UTC
    Forking and threading are two fairly different things. I can even see situations where you would want to do both at the same time. Overlooking the fact that threads don't seem to work as well cross-platform as forks do, and that I haven't done any real work with threading (not in perl), I'll give my opinion anyway:

    When you fork, the child program and parent program really do go their separate ways. Ignoring the few signals and what not that tie them together, they are now separate programs. They shouldn't be talking to each other, except possibly by signals and in desparation, shared memory. They can do some very nifty things, like the Apache server which runs as root, but forks off children that run as nobody - which is part of the reason it has the best reputation for security. Even a hacked Apache server is mostly useless - the best you can do is vandalise the website. Note here that Apache's children do not communicate (much if anything) back to the parent. If you wanted to have the children change variables in the parent, you really want threading.

    Threading is extremely nifty when you want the program to momentarily 'split' and then 'recombine'. Nothing is better for updating a user interface while waiting on a port than threads.

    Of course you could do both at the same time - listen on multiple ports and then fork children. It's no accident that Perl is better at forks - Unix in general is better at forks. But it is a hammer that gets used on a few too many problems.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

[reply]
      I can even see situations where you would want to do both at the same time.

      Really? When?

      Butenhof warns against it ... "avoid using fork in a threaded program (if you can) unless you intend to exec a new program immediately". (Programming w/ POSIX Threads p197).

      There are lots of complications associated with it. In pthreads, only the thread that calls fork exists in the parent. But it does have a copy of all the mutexes etc that existed in the parent. So you must define a 'fork handler' which allows you to do certain cleanup at the time the fork happens (in the parent and the child).

      I think it would be a case of mixing fairly incompatible paradigms ...

      --
      Ash OS durbatulk, ash OS gimbatul,
      Ash OS thrakatulk, agh burzum-ishi krimpatul!
      Uzg-Microsoft-ishi amal fauthut burguuli.

[reply]
        You can have a nonthreading parent whose children use threads for their business easily then, by your explanations. As I understand, that's a bit like what Apache 2.0 will be doing, which, too, mixes threads and forks largely depending on platform.

        Makeshifts last the longest.

[reply]
Re: To thread or not to thread
by Elian (Parson) on May 30, 2002 at 15:28 UTC
    Threads are unsafe in perl right now regardless of what you do. IThreads may be safe in 5.8.0. (Probably will be, but there's always the possibility something niggly gets through)

    If you're really careful, 5.005-style threads are safer than IThreads (what Windows uses to fork) through 5.6.1, but only because you can protect yourself better from the places where you can core perl.

[reply]
      Also note that while ithreads in 5.8.0 may well be thread safe, that doesn't mean modules running under 5.8.0 will be. Particularly anything that uses XS. Some stuff will be fine, no doubt, but others will need major overhauls.
[reply]
Re: To thread or not to thread
by tadman (Prior) on May 31, 2002 at 05:53 UTC
    Now you've got me wanting IO::Pipe::Interdimensional.

    Threads are way better than processes if you can use them effectively, as you can share data instantly. As long as you're careful about locking everything down, it's fine. BeOS was a great introduction to how massive multi-threading can be a Good Thing.

    The only unfortunate part about mod_perl is that 2.0 isn't "threaded" so much as "thread aware". Maybe the Perl 6 mod_perl will fix this and life will be Good. One of my biggest grumbles about mod_perl is that you have all these processes with exactly the same data, and no easy way to share it. IPC::Shareable is only so good.
[reply]

Back to Meditations