That is exactly what I am suggesting is possible. But you won't find the method documented anywhere, nor any example code that uses it.

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

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

I have more than once wanted a cache of objects, sharable between threads. Because there's no such beast, the cache ends up living in some external storage and the objects are unmarshalled/marshalled for each access.

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

With current ithreads implementation, this solution is not as elegant as it could seem. Creating a new thread can be a very expensive operation (in terms of both CPU and memory) that depends on the in-memory size of the runtime. So you can not pretend that threading business are completely hidden behind your class API.

I have this problem when porting Net::SFTP::Foreign to Windows: I needed to do non-blocking IO on a pipe, but windows only supports select on sockets. Using threads to handle IO would be the best alternative (one thread for reading from the pipe and other for writting), but I found it unacceptable because I knew nothing about the caller. For instance it could be a program using 500MB of RAM, and starting the two new threads would triplicate that!!!