erry D. Hedden wrote: > Look at $x: > REF(0x144f8f0) > REF(0x144f8f0) > REF(0x144f8f0) > REF(0x144f8f0) > REF(0x144f8f0) > REF(0x144f8f0) > > First look at $y: > SCALAR(0x1423c70) > SCALAR(0x1423ad8) > SCALAR(0x14bd968) > SCALAR(0x14bd980) > SCALAR(0x14bd998) > SCALAR(0x14bd9b0) > > Second look at $y: > REF(0x1423c70) > REF(0x1423ad8) > REF(0x14bd968) > REF(0x14bd980) > REF(0x14bd998) > SCALAR(0x14bd9b0) > > Seems to me that this is a bug. It shows that > threads::shared isn't detecting that it's dealing with a > circular reference. With each level that the app traverses, > threads::shared "unrolls" another version of the shared > variable.
> The more I think about it, the more I'm convinced this needs > to be fixed. The original variable $x is a circular > reference, and it's finiteness is detectable. The copy made > to $y has become an infinitely deep reference with lazy > evaluation. I've been looking at how to fix this, but know understanding of the internals of threads::shared is weak. Conceptually, I think it would require keeping a weak reference of each private SV associated with a shared SV. This would need to be done on a per-thread basis. Then when a thread tries to reference a shared SV, a lookup would be made to see if a private SV already exists (and still exists) for that thread. If so, that is returned (and the ref count of the weak ref is incremented?). If not, a new private SV is created, and a weak ref to it is appropriately stored. Is this a logical approach? If so, is it doable?
