Fundamentally, I don't think that there is much to choose between our positions. I chose that example a) because it was a recent real problem; b) because I knew that it lent itself to a simple solution. In your terms, it was embarrassingly parallel.

I'm trying to say that (like security and quality) threads are not something you can just smear on some code and get benefits. Analysis and design are required to make it work

No argument there.

The counterpoint I was trying to make, is that the explicitly-shared-only nature of iThreads simplifies a whole class of data-parallel algorithms to an extent that in many cases it is no harder--and often easier and with additional benefits--to thread programs of that type as it is to multitask them through forking.

You get similar benefits of effectively separate dataspaces; but avoid requiring IPC to communicate results from the concurrent tasks back to the parent for coalescing. In this way, iThreads are different from most other forms of threading, and quite unique. That's not to say they do not have their caveats.

I will grant that I do not have as much experience with iThreads, but every solution that I have run across that makes threading really easy, has turned out to have major caveats.

And that's perhaps the main point I was trying to make. iThreads are different. And the caveats one needs to be aware of are different from other forms of threading.

Some of them are related to the kinds of problems one encounters when using other forms of kernel threading, but they tend to manifest themselves in different ways.

Some of them are exactly the same as with those others forms, but only really come into play at the perl internals level. That is, at the C-level, where threading is just native kernel threading, all the normal kernel threading caveats apply--but the Perl programmer does not need to, (and indeed, in many cases, can not), concern themself with them. If the Perl internals guys have done their job correctly, they are not an issue to the Perl programmer. If there is something the internals guys have missed, there's nothing the Perl programmer can do about it other than avoid the problem.

And there are a new class of caveats that are unique to the current implementation of iThreads. Some of these arise because of exactly the reasons you mention above, the belated application of threading to a previously single threaded application: Perl. Some, arise because of the need to retain compatibility with the pre-existing designs, architecture and concepts and expose weaknesses in that pre-existing design.

Experience of other threading systems frequently does not hold true when working with iThreads. Some good experiences and rules of thumb from other systems will fail dismally if you try to apply them to iThreads. Previous absolute no-nos can be used with scant disregard.

The concepts of iThreads, and the current implementation of them, are sufficiently unique, that experience of other systems has to be subject to test and verification before applying them to the design and implementation of iThreaded applications.