in reply to Re^7: semi-panic: attempt to dup freed string?
in thread semi-panic: attempt to dup freed string?

Okay. Ignore the previous reply. The penny has dropped.

I can't store a reference to an SV allocated by perl inside my struct, because when a thread ends, the referenced SV will be GC'd and I'll end up holding a reference to a freed scalar.

Your fix is to allocate an SV yourself, and assign a reference to it into the struct. And the set() copies teh contents of the inbound SV, not assign a reference to it.

The code in the DESTROY() method is there to clean up the SV you allocated, but the TODO is because you haven't found, (or have, but haven't yet implemented), a mechanism to decide when to free the struct and it's contents. I think I see a way to do that.

I think this gives me what I need. For that, and your time, I thank you.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^8: semi-panic: attempt to dup freed string?

Replies are listed 'Best First'.
Re^9: semi-panic: attempt to dup freed string?
by ikegami (Patriarch) on Mar 25, 2011 at 20:02 UTC

    Couldn't have said it better :)

    For the memory problem, a simple solution might be to have two classes.

    my $buffer = Buffer->new(); # Creates a buffer and blessed SvUV. my $shared = $buffer->share(); # Creates a blessed SvUV. async { $shared->set(12345); }->join(); undef $shared; # Does nothing. say $buffer->get(); undef $buffer; # Frees the buffer.