bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Termination behaviour


From: Juergen Sauermann
Subject: Re: [Bug-apl] Termination behaviour
Date: Mon, 09 Feb 2015 14:28:31 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hi Dirk,

I guess you need to ensure that the static destructors, in particular the destructor for Workspace::the_workspace is
being called. There is no destructor ~Workspace() declared so the compiler creates one automatically.

In case of shared libraries, if they are C++ then statically constructed objects should be destructed
when the shared library is dlclosed() (if you dlopen()/dlclose()) If you link against another program
instead of dlopen()/dlclose() then the destructor will be called when the program terminates.

If you build a C library then things may be different (and possibly also on some other platforms).

cleanup() should be called at some point  but it only restore settings made by GNU APL (colors etc) but it
does not call destructors of static objects.

As a hack, you could also try to call __do_global_dtors_aux() or _fini() of the library manually, but be be aware that they
may be called again at a later point in time (and will then crash).

The man page for dlclose() says this (probably meant for C rather than C++ libraries):

       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 suppose that a C++ library will do that automatically for static C++ objects.

/// Jürgen




On 02/09/2015 06:23 AM, Dirk Laurie wrote:
Hi Jurgen:

Since merely loading libapl.so (which is all of GNU APL except main.o)
creates an APL workspace, the question of clean termination arises.

I have experimentally determined that )OFF does not call finalizers
on the Lua side. This is unacceptable, since Lua provides a facility
for programs to create custom-defined finalizers. Hence I must
disallow )OFF.

In the C interface, I can create a custom finalizer that will call
`cleanup(true)`.

Have I missed some subtlety?

Best wishes
Dirk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]