Re: Calling call_atexit() to clean up stuff initialized in BOOT

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:[email protected]

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/