There isn't one. Like I said, I haven't had chance to do any real testing yet. I only realised it might work just over a week ago and most of my time has been taken up with something else.

But that misses the point of my question. You said:

My main problem with it is that there is no common way of creating shared/shareable, object oriented libraries.

Personally, I'm far from convinced that sharing objects between threads is a good idea, even if it is possible to do easily and safely. This is a distinct problem from that of creating thread-safe libraries.

At the perl level, the latter is simply a matter of discipline of behalf of the module authors. Most of the problems that exist with existing modules in this regard stem from non-reentrancy in C/C++ libraries that the perl modules wrap. That cannot be directly addressed by Perl or iThreads.

For the former, I've yet to see a convincing application for shared objects. Do you have one?

For most applications, the concurrency requirements of an object can, and should, be catered for by using threading within the objects, not external to them. That is to say, if an object has to do something that may take a long time, or block waiting for some external IO event, then the object should expose three methods:

1. $obj->startLongOrBlockingProcess()
2. $obj->isProcessComplete()
3. $obj->getProcessResults()

This approach allows the object owning thread to multiplex many such objects without concerning itself with any of the problems of locking or sharing or synchronisation, because they are all taken care of within the class, not by the users of the class. I'm not saying it will solve every application of threading and concurrency, but it will solve a large percentage of them and is available in Perl, right now. And has been for a while. The real lack here is of documentation. A lack of a "Threading Best Practices" document to guide people. And that lack has as much to do with the fact that there are simply not enough people tackling real problems using iThreads, as it is to do with any inherent limitations they have.

The purpose of my question was: if this ability was available and easy to use, would that satisfy your concerns about iThreads? Or would it simply shift your concerns to some other limitation?

You see, it appears to me that for the most part, the detractors of iThreads haven't tried to use them, or encountered the limitation themselves. They simply read "bad stuff" about them, usually written by people who've made one attempt to use them, got bitten, usually by bugs that existed in the early builds (what perl feature didn't initially come with bugs? ).

it's like people who say they would never buy an electric car because they do not have a 400 miles range, without considering that most people rarely drive more that 150 miles in one day except for once or twice a year.

And that's how I view most of the criticisms of iThreads. "they are unusable because of X, Y & Z", without ever considering whether X, Y or Z are ever needed, or whether there are alternatives to one or more of those.

You must be aware that I am far from entirely positive about iThreads, but as I've attempted to demonstrate when suitable questions arise, that they can be used to solve a very large number of problems more simply than the alternatives. Just as (say) regex are not suitable for solving every parsing problem, it doesn't mean you have to resort to a "proper parser" to tackle everything. So it is with iThreads. They do not solve every concurrency problem, but those that they do solve are far easier using them than any other solution.

The archetypal fall back attack on threading is the that old red herring of deadlocks. The easy way to avoid deadlocks is don't program them. That is to say, if you architect your code to not allow them to arise, then they do not occur.

Too simplistic? Well consider another old red-herring: reference counting and circular references. According to some people, perl's memory management is unusable, because it uses reference counting and that means that circular references can cause memory leaks. And yet, thousands of perl programs run day in, day out using that "flawed" mechanism successfully.

Addressing iThreads limitations today does not require adding layers of further complication, it requires understanding those limitations and looking for simple ways of avoiding them.