On 21-11-2014 23:23, Viktor Dukhovni wrote:
On Fri, Nov 21, 2014 at 04:13:58PM -0500, Jeffrey Walton wrote:
A fixed amount of memory that is not deallocated and is independent
of the number of operations performed, is NOT a memory leak.
Languages like Java and C# can continuously load and unload a library.
You will see a growth in memory usage because the memory is not
reclaimed.
Unloading of shared libraries is generally unsafe.  Loading and
unloading of pure of Java packages may work well enough, but I
would expect a Java runtime that unloads native libraries to stay
running for very long.

That is horribly outdated information and an assumption that no
competent library author should make or rely on others to make.

On modern systems, unloading of shared libraries that are used
as plugins, and by extension any shared libraries that might be
referenced by plugins without being referenced by the plugin-using
application core, is a normal and frequent operation supported
by the core shared library loader and most shared libraries.

If a library contains code that needs to be automatically called
when it is loaded or unloaded without that being an exposed API
level init/cleanup function, then the library porter needs to do
the target specific gymnastics to get called by the (C) runtime
at the appropriate times, and it needs to deal with common
restrictions on what such calls from the (C) runtime are not
allowed to do (one of which is recursive calls to the dynamic
loader API).  For libraries written in C++, the static constructor
and destructor language mechanisms are treated this way
automatically and thus subject to the same limitations on
permitted operations.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to