Ostensibly, starting a new interpreter in a second thread is as simple as starting one in your main thread.
And whatever you load into that interpreter will be completely separated and isolated from any other thread+interpreter you happen to have running -- so long as you stay away from process global entities, like the environment, filehandles etc. And that's where things start to get complicated.
You can even get creative and switch the interpreter contexts around, so that you effectively break the 1 thread tied to 1 interpreter link.
Running isolated interpreters is relatively trivial, the problems arise when it comes to communicating between them, and sharing memory. And that's where the iThreads coders went "wrong"(*). They opted to use a 'clone everything' implementation, which whilst meeting their brief -- to provide a fork emulation on Windows -- creates all (literally all) of the perceived problems that have been (incorrectly) labeled as the "heaviness of threads". The heaviness lies entirely with the attempt to provide Copy-On-Write semantics without the use of Copy-On-Write OS support. It means you have to copy everything up front just in-case it gets written to. (Which is all the more
The second big problem with Ithreads, namely the size cost of shared memory, is equally frustrating, because it is equally fixable!
For example, when you create a shared array, a (bog standard) array is allocated in 'shared space'; and then each thread that accesses it gets a tied array that 'redirects' reads and write to the shared array. But the dumb bit is that the tied array in user threads consist of a tied (standard) perl array of tied scalars. Tied scalars (with their associated magic) are bigger than most ordinary scalars; which means that the 'placeholder' tied array is often much bigger than the actual shared array! Which is a nonsense.
The entire tied array could consist of a single blessed scalar containing a reference to the shared array. Full stop. When a FETCH or STORE (or any other tied array method) is invoked, the arguments provide all the required information to allow the shared array to be access and/or modified. Imagine how much lighter (and faster) shared arrays would be, if each thread only required a single shared scalar placeholder, instead of a full array of (fat) shared scalars!
Likewise for hashes; And %ENV; and for filehandles; and all other process global entities.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.
In reply to Re^4: Trying to Understand the Discouragement of Threads