On Thu, Mar 12, 2009 at 5:15 AM, Gregor Goldbach <goldb...@dfn-cert.de> wrote:
> Nicholas Clark wrote:
>
>>>> 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?
