I you don't need inter-task communications, then I agree, but the biggest problem people have with using threads is trying to use them in the same way that forks are used. This is true of whether using iThreads or pthreads, or most other forms of threading.

Just as Perl requires the adoption of a different way of working to C if you are to realise the best from it, so once you have relatively easy inter-task communications, a different way of working and thinking is called for.

And there are other platforms than the unix-like world.

IPC is weakness of multiprocess models, and I'm disappointed that everyone has been content to stick to the same IPC mechanisms which have been around since day one. I'd rather prefer if the amount of effort that has gone into threads in the Unix world at large had gone into making it easier for forked processes to communicate when they need to. A highlevel language like Perl where variables are more than just names for memory locations offers particularly great opportunities to hide much of the drudgework of IPC from the programmer.

Defaulting to no shared memory is inherently safer than defaulting to all memory being shared, and on modern CPUs with useful MMUs forking doesn't even cost a single extra cycle. Threads are implemented in terms of fork() in the Linux kernel.

Threads are mainly useful as a way to regain some of the fork() semantics on amputated platforms that don't natively offer something equivalent. Indeed, the iThreads you so like, in various respects behave more like forked processes than like ye olde threads.

Makeshifts last the longest.

Threads are mainly useful as a way to regain some of the fork() semantics on amputated platforms that don't natively offer something equivalent. Indeed, the iThreads you so like, in various respects behave more like forked processes than like ye olde threads.

Aristotle Quit doggin' me.

A platform that chose a non-forking model of multi-tasking isn't "amputated", it just made different--I would contend, more modern and sensible; but don't let's get into that argument-- design-time choices.

The biggest single problem with iThreads is that they attempt to emulated that model of operation.

I simply try to make best use of what is available, and counter the (ongoing) FUD that they are unusable. And I think that I have demonstrated conclusively that used properly, they can be used very effectively.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

I you don't need inter-task communications, then I agree, but the biggest problem people have with using threads is trying to use them in the same way that forks are used. This is true of whether using iThreads or pthreads, or most other forms of threading.

Frankly, my biggest problem with using threads in Perl is that the implementation isn't very good. It's slow, uses a ton of memory and has some very non-intuitive restrictions. It feels exactly like what it is - a second-rate feature added as an after-thought.

-sam

It's slow, uses a ton of memory

The following code spawns 100 threads in under 2 seconds and uses < 40MB?

>perl -Mthreads -le"print time;@t=map{threads->new(sub{sleep 300})}1..
+100;print time;<>"
1107144770
1107144772
[download]

I agree they aren't doing much, and that is probably considerably slower than you can spawn 100 processes--but if you need the parent to communicate with the children and vice versa, then you'd need to a lot more work using fork.

It is true that there are some inconvenient restrictions (some of which could be alleviated), and you do have to learn a few simple techniques for getting the best from them--like not loading anything you don't want shared before you spawn your threads--but they are stable and very usable.

On Win32, they are infinitely preferable to fork, but I realise that that is a restriction of the platform. I can well see why anyone on unix wouldn't bother with them unless they really needed bi-directional communications.

I agree that the implementation is imperfect, but having spent a little time looking into the work that they are doign, I think teh guys that got them to where they are are did an brillaint job given the task they faced.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.