Init_ Fini_ shared objects

[idle]

With a shared object should we be supplying Init_() and Fini_() functions in our libs if the shared library is going to be used by more than one process?
If Fini_() wasn't provided in the lib wouldn't that mean that the memory used by the shared object wouldn't get freed
until the reference count drops to 0 ?

Then reading the man I see that they're depreciated but if I want to use them and I need to put the "-nostartfiles"
parameter on the command line.

It then goes on to say I should be using __attribute__((constructor)) and __attribute__((destructor)) instead, right!
I guess they're macros.

So the question still stands do we need to free the memory per instance of a shared object?

[remi_meier]

If you don't make an effort in keeping memory
alive over process exits you will never leave any
memory behind (or it could be considered a
kernel bug).
When you load a shared object, the pages of
the .SO will be marked as Copy-On-Write for
the loading process. If that process modifies
anything in those pages, they will first be copied
into the process' own virtual memory space.
That also means that any of the modifications
will be lost when that process exits, because
then all its pages will be "freed".

So, whatever you do in a .SO will actually only
happen in one process' virtual memory space
and therefore will be lost when that process
exits. PB should take care of initializing its internal
state in those init-functions on its own. You do
not have to do anything there.

That said, I never got a shared object compiled
with PB to work in other languages and therefore
couldn't check if it does what it is supposed to
do

[idle]

Thanks, I'm just in the habit of cleaning up on exit
and wasn't sure why there wasn't an obvious equivilent of attachprocess and detachprocess
I'm not sure what I was thinking, it's fairly logical to assume that the memory would get freed when the .so is closed
none the less it would be handy to work out how to use the macros