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"
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
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
