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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.