develooper Front page | perl.ithreads | Postings from May 2008

Re: p5p summary: Improving threads::shared ?

Thread Previous | Thread Next
Jerry D. Hedden
May 5, 2008 11:52
Re: p5p summary: Improving threads::shared ?
Message ID:
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

Is this a logical approach?  If so, is it doable?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About