develooper Front page | perl.perl5.porters | Postings from May 2013

Re: [perl #118139] Storable in DESTROY blocks

Thread Previous | Thread Next
Steffen Mueller
May 28, 2013 18:40
Re: [perl #118139] Storable in DESTROY blocks
Message ID:
On 05/23/2013 09:41 PM, Reini Urban wrote:
> On 05/23/2013 10:58 AM, Leon Timmermans via RT wrote:
>> On Thu, May 23, 2013 at 5:45 PM, Steffen Mueller <>
>> wrote:
>>> There's a more general problem with this: occasionally, C extensions
>>> need to
>>> do cleanup very late during global destruction. Usually just a free() or
>>> Safefree() to be done after all Perl code is done. Maybe adding a C
>>> level
>>> hook for this could allow Storable to work around this problem as well?
>>> Given what you write, I think maybe not that easily.
>> That would not solve this problem. This problem is not in a DESTROY
>> from Storable, but from other code calling Storable from they DESTROY
>> methods.
> DESTROY in Storable in part of the problem.
> We have to die in Storable if called during destruction, because
> Storable has its own DESTROY block which frees ctx, and you are not
> allowed to access that then.


Ideally, I think using a scheme like we have for Sereal might be the 
ideal solution, but I doubt any of us will volunteer to hack that into 

The "context" object (encoder or decoder for Sereal) are C structs 
wrapped as Perl objects. You can either explicitly construct one, or, if 
you use the (slower) functional interface, one gets created on the fly. 
These on-the-fly structs have a flag set that indicates wherever they'd 
normally be cleared, they're instead free'd.

The volatile part of the encoder/decoder state is cleared by pushing a 
callback on the save stack. Until cleared, the state is marked dirty.

To avoid concurrent use issues (or calling back into Sereal during 
exception handling before it's cleaned up), Sereal will detect when 
you're trying to use an encoder/decoder that's already dirty and then 
helpfully create a clone of the static parts (the settings) without the 
volatile state. These clones will always also have the "free instead of 
clear" flag set.

Sereal doesn't have state that fundamentally needs clearing at 
interpreter exit. Presumably, Storable has that mostly to allow the 
functional interface to be faster? If so, as Vincent recently pointed 
out, call_atexit() could help?


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