(It's actually quite trivial to start a new thread running a completely, clean, empty interpreter ....)
How? Is there any module which does that?
Actually, I would prefer something that would allow me to start an empty interpreter, run some initialization code inside and then, clone it on-demand and run arbitrary code on the clones (I toyed a couple of times in the past with the idea of doing something like that myself... but never got the tuits).
| [reply] |
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 dumb frustrating as Windows does actually support Copy On Write memory!)
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.
| [reply] |
If I'm not mistaken, the previous implementation of threads tried the "share all" way and failed miserably so the ithreads were developed to have something that, even if heavy, at least ... works.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
I haven't used it, but I think threads::lite does just that, spawn a mostly separate interpreter with a fresh (OS) thread. It also sets up some communication channels between the main thread and the new thread, but it shares nothing.
Judging from the caveats in the documentation, loaded modules stay loaded, but all local namespacess with imports seem to be wiped. So it's not a completely clean interpreter but roughly equivalent.
| [reply] |