Calling call_atexit() to clean up stuff initialized in BOOT

[Steve Fink]

I understand initialization of an XS module may be modified using
BOOT.
However, there seems to be no counterpart of BOOT. How do I e.g. free
memory I allocated in BOOT?

[...]

Or is the current practice to write an XS function that e.g. frees the
memory allocate at BOOT and call it in an END handler in the module's
Perl code?

[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. It needn't be visible in your interface, so it doesn't really
matter whether you are doing things in a function- or object-oriented
style.

our $__WEAREALLGONNADIE = bless {}, 'My::Package::Cleanup';
sub My::Package:Cleanup::DESTROY {
cleanup_function_written_in_C();
}

In my case, I was explicitly destroying the symbol table, so I knew
that everything was still alive everywhere but in my custom-created
packages.In your case, this would end up in the scary global
destruction phase as others have pointed out. But if that bothers you,
why aren't you just using an END block again?

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.
Stop worrying about it. It's dead, and the house it lived in is now a
strip mall.

That said, there are plenty of ways to allocate resources or perform
actions that will outlive a process -- shared memory, files, message
queues, emails to ex-girlfriends, etc. But it doesn't sound like what
you're worried about. 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,
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?

[Nicholas Clark]

I understand initialization of an XS module may be modified using
BOOT.
However, there seems to be no counterpart of BOOT. How do I e.g. free
memory I allocated in BOOT?

[...]

Or is the current practice to write an XS function that e.g. frees the
memory allocate at BOOT and call it in an END handler in the module's
Perl code?

[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?

You can use the SAVE* macros to trigger events at scope exit, which is useful
for resources allocated inside a given XS function, that must be disposed of
when that function exits, normally or via an exception.

But that's not going to do what you want in your BOOT example - it would free
things at the exit from the BOOT routine.

Nicholas Clark

[Gregor Goldbach]

Post by Steve Fink

[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. :)

;-)

Post by Steve Fink
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.

Post by Steve Fink
[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.

Post by Steve Fink
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.

[...]

Post by Steve Fink
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.

Post by Steve Fink
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: [phone] Fax: [phone] Mail:***@dfn-cert.de

DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone [phone]
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/