Note: I have posted this a meditation, since the question is rhetorical.

Yesterday, I asked for some help on the Chatterbox, building an ithreaded perl 5.8.0 on Solaris (which I still have not achieved). This prompted a response from merlyn, of the form "threads, threads, threads... Why is everyone obsessed with threads?"

There followed dscussion on the CB on the merits of threading and forks. I attended a London Perl Mongers meeting last night, and discussed the subject some more over beers.

The subject has been raised many times before on SoPW:
Thread vs. Fork
Threads vs Forking (Java vs Perl)
Threads, Forks, or Nothing?
Multithread / Fork Perl Examples.
To thread or not to thread
Status and usefulness of ithreads in 5.8.0
ActiveState, threaded fork and re-entrancy

My conclusion is that it really depends on exactly what you are trying to achieve in the multitasking. If the tasks are completely separate, they would benefit from separate address space, hence fork. Unfortunately on Windows, you haven't got a real fork, so perl does the best it can under the circumstances.

If what you want is cooperating tasks with much communication, such as shared memory structures, threads are a better model. The ithreads mechanism provides all the primitives to achieve locking etc. using method calls. Child processes can talk to each other, but you need to use an IPC mechanism such as pipes.

Replies are listed 'Best First'.
Re: Threads versus fork, which to use?
by pg (Canon) on Feb 08, 2003 at 05:59 UTC
    We have to realize one thing, Perl has been there for such a long time without thread, and "real" thread didn't exist in Perl until 5.8 came out. For the following reasons, I would expect that, fork would still be heavily used, although thread would slowly pick up, just like in all other language environments and design patterns:

    1. Momentum. Perl developers are more familiar with fork from their past experiences. They have developed and established their design patterns over years, especially for people who do not have thread experiences with other languages.
    2. Fork has its own benefit, especially when components under question are loosely coupled.
    3. Perl thread still misses lots of important features, which makes developers feel less comfortable with it, than they do with fork. Base on my experience with Perl thread after last couple of months, I see those serious problems:
      1. Perl thread does not allow OO object being shared among threads, because bless has not yet been implemented over threads.
      2. Perl's sharing mechanism is heavily hacked, and does break lexical scope. For most of other major languages, variable sharing is achieved through normal parameter passing, but in Perl, you have to explicitly declare variables as shared, and those variables being shared then act as "globals" over threads.
      3. Developers have very limited, if not zero, control over the behaviors and attributes of thread, for example, priority etc. This clearly indicates that Perl is not ready for sophisticated multi-threaded application.
      4. Perl's way of locking is heavily hacked. In most of other major languages, locks are not directly put on variables, instead they are used against a middle layer, for example mutex etc, but perl's lock goes directly against variables, which makes the locking seriously less flexibale. Again, as OO is not supported over threads, layered locking against complex data structures becomes extreamly difficult, if not entirely impossible (with a reasonable amount of affordable effort).
    After said all this, however, Perl's thread is useful and usable, as long as you don't use it for complexed multi-threaded tasks, or try to share and lock complex data structures.

    So far I consider perl's thread safe for simple data structures, such as regular scalar, scalar ref, array, array ref, hash and hash ref. Keep one thing in mind, don't share complex arrays and hashes (for example, HoH, HoA, AoAoA), I consider this as very unsafe, very difficult to share and lock them properly, and requires too much developing effort.

    One last experience to share: Perl gives all of us a very big benefit, comparing to other languages, that it requires much less development effort. But when it comes to multi-threading, at this stage, perl requires much more effort than other languages do, and the outcome is much less ideal.
[reply]
Re: Threads versus fork, which to use?
by Juerd (Abbot) on Feb 07, 2003 at 21:04 UTC
[reply]

Back to Meditations