|
From: | Elias Mårtenson |
Subject: | Re: [Bug-apl] )ERASE and )CLEAR erases native functions |
Date: | Fri, 18 Apr 2014 23:44:56 +0800 |
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,
EliasOn 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
[Prev in Thread] | Current Thread | [Next in Thread] |