Whenever a PMC gets "shared", it would get changed read and write function slots of the applicable vtable entries that would add mutexes around all accesses to that PMC.
Yep. That was my conclusion too. A shared PMC will be a variant of the plain one, where all vtable methods that change something are protected by mutxes. Additionally I think its best, to put these PMCs into a separate PMC memory arena, because DOD on shared PMCs is a bit different - but I din't think about that very much yet.
Most important thing to note here is that changes are made only when something is happening inside the thread, _not_ when a thread is started (apart from the adaptation of the "write" functions when the very first child thread is started).
With that approach, we violate one Parrot paradigma: "The address of a PMC doesn't change during its lifetime". So I don't see currently a way to avoid copying non-constant non-shared PMCs on thread creation.
Hope I had enough understanding of vtables and PMC to make sense.
It makes sense, I'd rather have such COWed PMC write semantics, but I fear "The big cheese"[1] will not like it.
Liz
[1] s. CREDITS leo
