Steve Fink wrote: >> [perl objects] >> >>> Yes, but perl objects are going to be cleaned up (or at least, any with >>> DESTROY methods are going to get it called) before then, so that's somewhat >>> a red herring. >>> >>> But possibly also a solution - anything allocated in BOOT that is stashed >>> inside an object will get that object's destroy method called soon after >>> END time, with a live interpreter. >> I don't create any object in my XS module, it has a pure functional >> interface. Is there anything like a destroy function instead of a >> destroy method? > > If creating objects disturbs you, then think of it as creating a > blessed reference. :)
;-)
> In the past, I have created a dummy object for more or less this
> purpose. [...]
>
> our $__WEAREALLGONNADIE = bless {}, 'My::Package::Cleanup';
> sub My::Package:Cleanup::DESTROY {
> cleanup_function_written_in_C();
> }
I think I was looking for something like this.
> [the scary global destruction phase]
> But if that bothers you, why aren't you just using an END block again?
I'm just looking for possibilities since I don't find anything about it
in the docs.
> Although this worries me: "Is there a common practice for cleaning up
> or do people just trust the OS to free everything when the process
> exits?" together with "Or is the current practice to write an XS
> function that e.g. frees the memory allocate at BOOT..."
>
> If you don't trust the OS to free up allocated memory, you are going
> to go insane for no useful reason. In what way would that memory be
> allocated if the process no longer exists? There's no place to put it.
The memory allocation was just an example. I've been brought up with the
principle to close a door when I opened it. So I like to close files,
free memory etc.
[...]
> The only reason I know of to explicitly
> deallocate memory when you are certain a process is dying anyway is to
> make it easier to track down true memory leaks without the
> distractions of spurious reports. There's also an aesthetic argument,
I'm in favour of aestethics, then.
> but it's less persuasive when you realize you're sacrificing
> efficiency. Why erase the writing on a piece of paper before throwing
> it in the fire?
Burn, baby, burn! :-9
--
Dipl.-Inform. Gregor Goldbach (PKI Team)
Phone: +49 40 808077-621 Fax: +49 40 808077-556 Mail:goldb...@dfn-cert.de
DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
DFN-PKI
https://www.pki.dfn.de/
smime.p7s
Description: S/MIME Cryptographic Signature
