|
Hi Elias,
the dlclose() man page recommends this:
Instead, libraries should export routines using the
__attribute__((con‐
structor)) and __attribute__((destructor)) function
attributes. See
the gcc info pages for information on these. Constructor
routines are
executed before dlopen() returns, and destructor routines
are executed
before dlclose() returns.
I thought a C++ destructor has these attributes automatically, not
sure though.
/// Jürgen
On 04/18/2014 02:41 PM, Elias Mårtenson wrote:
Point taken.
Would it make sense to provide a callback to the
native library when the function gets erased? Then the library
would be able to close everything cleanly (if it's able to) and
it could then return a code to GNU APL indicating whether it's
OK to dlclose() or not.
The default would be to not dlclose of course.
I think I could make the SQL library unload safely in
this case.
Regards,
Elias
On 18 Apr 2014 20:38, "Juergen Sauermann"
< address@hidden>
wrote:
Hi Elias,
I believe that currently )ERASE or ⎕EX cause the native
function to be removed
from the APL symbol table but the .so file is not dlclosed()
and the native function
object is not removed.
The .so file and the native function object are typically very
small by today's
disk size and memory size standards, so I would rather leave
it this way.
Main reason is that we can't really know what happens inside
native functions
and dlclosing() a lib can have disastrous effects.
/// Jürgen
On 04/17/2014 06:56 AM, Elias Mårtenson wrote:
Is it per design to be able to )ERASE native functions?
There is currently no unload capability in the native APL
(and frankly, I'm not entirely sure it's always reasonable
to assume that such functionality can even be implemented
with any degree of stability).
With that in mind, does it make sense to be able to erase
them?
Regards,
Elias
|