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.

I'm not advocating the "share all" way. Absolutely not. Actually what I'm advocating is share less. Indeed, only share what I ask to share; and only when I ask to share it.

What makes iThreads heavy, is not the threads, nor the 'protected' memory of normal lexicals; it is the wholesale cloning of the process global state -- %ENV, file&dir handles, special global variables; etc. etc. -- every time you start a thread. What I'm advocating it to skip all of that entirely. It only makes sense because they are trying to emulate fork, where all that stuff has to be cloned, because you're starting a new process, so the new process cannot access the process global state of its parent. That simply isn't true of a new thread; and duplicating (for example) stdin/stdout/stderr simply makes no sense. having cloned them, they are still connected to the same place, printing from one thread still conflicts wth printing from another thread, so what did you gain by cloning them? Nada.

And the second thing that makes threads "heavy", is the duplication of everything that has been loaded, or instantiated into the current thread before the clone. This is *never* what I want in a new thread. Again, this only makes sense in the context of fork emulation; and fork emulation only makes sense if it allows unix scripts that use the forking paradigm to run unchanged on the emulating platform -- ie. windows -- but it doesn't! Signals would have to accurately emulated; and they aren't (and probably can't be!). Non-blocking IO would have to work the same; (it could be made to, but it doesn't). The fork emulation is almost completely useless.

But interpreter threads with complete segregated memory, works. And works well. So well in fact that the concept is being used in just about every new programming language that provide kernel threading. And, as you mentioned, and as the previous Perl threading experiment proved, given the nature of the old-fashioned programming style used by Perl's internals -- global state ($/,$\,$" etc.); static tables & god objects; non-reentrant functions et al. -- it is the only way to retro-fit threads into it.

But completely isolated threads throws away one of their major advantages: the ability to use divide and conquer threads upon (shared) large, homogeneous datasets. So you need a way to share state; which is currently implemented by threads::shared, but in a decidedly non-optimal way.

Now imagine that instead of the indiscriminate cloning required by the useless & unused fork emulation, you put all shared state -- all the globals and environment in addition to the shared lexicals -- into a single SHARED::* stash (similar to what is done for shared lexicals now, but with the addition of the process global entities (GSEs)), and then modify the GV* functions to lock and access that SHARED::namespace whenever a GSE is accessed.

Bingo! Isolated, interpreter threads, clean and empty at the point of spawning, with full, controlled access to GSEs. With a sensible implementation of thread::shared::tie to avoid the gratuitous use of memory that it currently uses, and you end up with threads that start faster & lighter, and have full access to GSEs and lightweight shared memory, whilst retaining the implicitly non-shared state of normal lexicals.