Re: Need help with bug fix for storing shared objects in shared structures

Jerry D. Hedden wrote:
> I'm trying to come up with a fix for the bug related to
> storing shared objects inside of shared structures.  The bug
> is that when any proxy objects for the shared object are
> destroyed, the object's DESTROY routine is called even
> thought the object itself should not yet be destroyed.
> 
> My problem is that my code (provided below) seg faults, and
> I can't figure out why.  Any help, comments, suggestions,
> etc. would be appreciated.

<snip/>

> 
> 
> I am attempting to fix this bug by first providing a call in
> threads::shared (ext/threads/shared/shared.xs) to report on
> whether or not a shared object should be destroyed:  If the
> ref is shared, and its refcnt is greater than one, then it
> should NOT be destroyed.

<snip/>

I can't answer the cause of your segfault (perhaps you can
supply a stack trace ?), but since you're hacking CORE
anyway, might I suggest a different solution that would
hopefully be much faster to execute (albeit more
of a pita to implement): creating a function pointer
ala PL_lockhook ? Unfortunately it appears defining
and init'ing lockhook is scattered around various
header/source files, and you'll need to create a new
funcptr type to take an SV argument and return an int.
But presumably it would run much faster (and be easily
hooked/chained by other modules that may need the feature, e.g.,
Thread::Sociable 8^>)

My $0.02,
Dean Arnold
Presicient Corp.