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