Front page | perl.perl5.porters |
Postings from May 2013
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 <smueller@cpan.org> >> 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. *nods* 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 Storable: 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? --SteffenThread Previous | Thread Next