Let's first address some of your points.

Threads can be created without replicating an entire process. Futhermore, some, if not all, of the work of creating a thread is done in user space rather than kernel space. When processes synchronize, they usually have to issue susyem calls, a relatively expensive operation that involves trapping into the kernel. But threads can synchoronize by simply monitoring a variable - in other words, staying within the user address space of the program.

It's not clear to me what kind of threads you are talking about. See, threads have been invented repeatedly, and in incompatible ways. Many modern operating systems have kernel level threads - that is, the kernel itself is aware of threads, and it may even treat them as processes when it comes to sceduling (but not all OSses do). OTOH, threads can be implemented entirely in a single process, without the OS being aware of it. I think some implementations of Java do it this way.

Now, forking on modern OSses is *cheap*. From the Linux fork() manual page:

Under  Linux,  fork  is  implemented  using  copy-on-write
pages,  so  the  only penalty incurred by fork is the time
and memory required to duplicate the parent's page tables,
and to create a unique task structure for the child.

Now, if we look at how Perl threads are implemented, you'll notice that quite a lot of work needs to be done to start a thread. Far more work then needs to be done than a kernel level fork().

The performance difference is also a winning point for thread over processes. The testing and prove of this itself can be a very big topic, and there are lots of numbers and well accepted testing results, which you can find all over the places.

Could you please post some benchmarking results of Perl threads vs Perl forking? Or post pointers to them?

When some of us are trying to avoiding thread, Perl creators is using threading as a selling point.

They are? I guess that's why ./Configure -des; make creates a threaded Perl. Oh wait, it doesn't.

Here are some reasons why I prefer to use forking over threading:

• If you want thread, you need to build a thread capable perl. But a thread capable perl is slower than a non-thread capable perl, even if you don't use threads. You're *always* paying a price.
• The fork()ing behaviour is cross-platform - or at least, it works the same on platforms I care about. Any mainstream UNIX knows how to fork(), and I get similar behaviour in Perl as in C. This kind of cross-platform behaviour (same in Perl as in C) is important to me (and probably others as well).
• Sharing data between threads in Perl is off by default. You need to enable it, and each access needs to be mutexed anyway. Might as well use shared memory.
• Forking is cheap, and done by the kernel. Perl threads are expensive and done in userland. Which for Perl means: bugs.
• I don't need a specially build Perl.

Abigail

---

---

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.