[RFC] clone semantics
allison at parrot.org
Thu Mar 11 20:00:58 UTC 2010
On 3/11/10 7:11 PM, Peter Lobsinger wrote:
> While I want the ability to do both deep and shallow clones, I think
> the responsibility for deep cloning is not something we want to push
> into PMCs if we don't have to. TT #1015 is caused by Hash PMC not
> being able to handle that responsibility.
This is a similar issue to the old method of creating Array/Hash
iterators, the current strategy is just too promiscuous with the
internals of the item it's traversing.
> The three visitor API PMCs that have already been created (ImageIO and
> ImageIOSize from trunk, VisitClone from tt1015 branch), use a hash
> (called 'seen') to keep track of this for PMCs, so can store arbitrary
> information about already visited elements.
> Eliminating duplicate STRING buffers is not something that is being
> done ATM, but would probably be fairly easy to add. AFAIK, you cannot
> communicate between components at a PIR/HLL level by modifying a
> shared string buffer because these are COW / immutable. So this would
> only be an optimization, not a functionality change.
> freeze/thaw/visit already take a parameter for the registry: PMC *info
> (also known as visit_info, visit).
> These PMCs are expected to provide a certain vtable-based API (I
> should document that somewhere)
Yes, please write up briefly for PDD 17, and pass the patch around the
list for review.
> but are free to provide that as they
> see fit. For example, freezing and cloning traversals can keep their
> state in a "seen" hash; marking traversal (which probably shouldn't
> allocate while traversing, but is hopefully unique per-interpreter at
> a given time) might keep its state in PObj flags.
To be clear, the "seen" hash is stored as an attribute of the VisitClone
PMC? And each deep-cloning process is a unique instance of the
VisitClone PMC, in much the same way that each iterator is a unique
instance of HashIterator/ArrayIterator?
More information about the parrot-dev