Maybe some optimizations could be added along the way: not cloning CODE (is it cloned now?)

Yes. Code is cloned now. And almost certainly always will be.

Perl5 was never designed for threading. Perl 5 byte code (opcodes or whatever you want to call then), were simply never designed to be reentrant, and it woudl be close to impossible to attempt to make them so now. But in reality, the duplication of code segments isn;t much of a problem, they aren't that big.

That said, I think it would be both possible and desirable to provide the ability to create a bare thread. One that only clones the process global state and nothing else, leaving the programmer to load just what he needs in a particular thread.

maybe marking SVs that are designed not to be cloned?

I agree. IMO, the only non-shared, non-process-global data that should be cloned are closures. I see no reason to clone unreferenced, and therefore unreferencable pre-existing lexical data.

It seems to me (without my fully understanding all the mechanisms and their implications), that this should be doable. Perl already has the ability to decide what are closures and capture them.

IMO the simplest and most effective change that could be made would be to remove the tie magic on scalars embedded in aggregate structures. Instead of having to clone a reference to every scalar in a shared array, you would only clone the reference to the array, not each of its elements.

I have some half working code that does this without requiring CORE changes. I might get it to work properly one day.

there were discussions on parrot-list that threading model is suboptimal and needs reorganization. Do you know anything about that?

No. I basically gave up on Parrot when I saw threading was essentially going to be left as an add-on. In needs to be built in from the ground up to work efficiently. I gave up again when I saw that the spec called for Parrot to support every kind of threading known to man and then some. Coooperative and preemptive; kernel and user; and event-driven and message passing and STM and Uncle Tom Cobbly an'all. Seems the easiest decision is no decision.

tcl ... what model

From what I read of your earlier tcl threading links, they appear to have gone a similar route to Perl--new interpreters in kernel threads. I didn't see anything about shared data; or whether code needs to be duplicated.

if using Tcl/Tk from Perl, using different threads but connecting to Tcl/Tk in a single-threaded-way - is it possible that Tk GUI could be used from any thread, without allocating a special thread for GUI only?

I know next to nothing about tcl and little about Tk. But I imagine the problems are very similar. Both were originally designed for strictly single-threaded operation so reentrancy was never a concern, never mind a priority. I think it would be equally difficult , essentially requiring a complete re-write to add reentrancy to them.

maybe its worth to write a disproof of her article?

I think not. It would be too little too late. Those that have an agenda against thrads will always choose to cite that reference no matter what refutations have been made.

I think - if you compile this current thread, make some kind of review - this could be a great advantage? You've put number of efforts explaining things, maybe these efforts could be reused?

I think that all the information is here for anyone interested to find it. Is there any advantage to moving it? And most of it has been said before and is there for those that look. I write best when it just flows from me. Once I start reviewing to any great extent, I get bogged down in the detail.

And anything formal, would need to be authoritative to stand up to close scrutiny, and there are still areas of the internal implementation that I simply do not understand and have found no ready reference for gaining clarifications.

If someone else wanted to try, I'd have no objections and would work with them to answer what questions I could.

Will you attend at nearest YAPC? (in Riga)

I do not attend YAPCs.