Re: [Bug-apl] )ERASE and )CLEAR erases native functions

[Elias Mårtenson]

The problem is that the __attribute__ feature is GCC-specific. And the other standard ways of handling callbacks when loading/unloading libraries (__init and __fini) are also non-standard (they work on Linux and Solaris to my knowledge but likely not on many others).

I can't really think of a better way than a dedicated callback function when the symbol is )ERASEd.

Specifically, I would like to rollback any active transactions and close all SQL connections when this happens.

Being able to tell the interpreter to unload the library is less important, although if the former is done, the latter is probably trivial to implement?

Regards,

Elias

On 18 April 2014 23:37, Juergen Sauermann <address@hidden> wrote:

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