|Title:||Automatic unloading of libraries for pluginlib|
In REP 116  pluginlib was enhance to support unloading libraries within the life cycle of the ClassLoader. In this REP the interface the user of pluginlib uses is revised to better support the load/create/unload cycle of shared libraries in order to permit unloading the library from memory when it is no more used.
The ClassLoader of pluginlib exposes the following methods:
These two methods provide a clear interface and semantic regarding the life cycle of libraries.
In order to instantiate a class from a library the user calls:
The issue with this implementation is that the user has no indication if createClassInstance() increased the library counter implicitly or not. Furthermore the user has to take care about the correct point in time when calling unloadLibraryForClass(). If two different entities are working with the same ClassLoader instance the library might get unloaded while it is still in use (i.e. A calling loadLibraryForClass(), B calling createClassInstance(), A calling unloadLibraryForClass(), results in unloading the library).
In order to not break existing code which relies on this current implementation detail the behavior of it can not be changes and is therefore deprecated (and later on removed).
Instead two new methods are introduced which provide a clear semantic for creating instances and handling the life cycle of the create instance.
Internally both will always call loadLibraryForClass() which ensures that the reference counter for the library is increased for every instance.
For createInstance() the ownership stays with the callee (the ClassLoader) and deleting and unloading is triggered by the deleter of the boost shared pointer. For createUnmanagedInstance() the ownership and responsibility to unload the library is transfered to the caller.
The common usage patterns would be:
The side effects of the existing and createCreateInstance() method in combination with unloadLoadForClass() are not fixable without potentially breaking existing application. Therefore the implementation of createClassInstance() is not altered in any way but deprecated. The additions will induce no effect on existing code.
The previous option to create an instance with autoloading disabled is not necessary since that case can be easily queried before and only conditionally call one of the create methods.
|||REP 116 (http://ros.org/reps/rep-0116.html)|
This document has been placed in the public domain.