|
> I believe that this happens during the copying of the object
> into the global stash inside of shared.xs. I have no
> experience with xs code, so I'm not sure, but it looks to me
> that only a thin copy of the object was done, not a deep as
> needed.
The comments in the XS file explain how threads::shared
work:
/*
* Shared variables are implemented by a scheme similar to tieing.
* Each thread has a proxy SV with attached magic -- "private SVs" --
* which all point to a single SV in a separate shared interpreter
* (PL_sharedsv_space) -- "shared SVs".
*
* The shared SV holds the variable's true values, and its state is
* copied between the shared and private SVs with the usual
* mg_get()/mg_set() arrangement.
*
* ...
The problem with storing shared objects in shared structures
involves the destruction of the 'proxy SVs': When the proxy
SV is destroyed, the object's DESTROY subroutine is called
even though the actual object is not being destroyed.
Here's my ignorant guess at what a solution to this might entail:
1. Modifications to the interpreter to not call DESTROY for
proxy SVs.
2. Tracking of the proxy SVs and modifications to the
interpreter to call DESTROY when there are no more proxy SVs
for a shared object.
|
