[ros-users] Draft REP: Automatic unloading of libraries for pluginlib

[Dave Hershberger]

Patrick's suggestion to return a LibraryHandle reminds me that I was
originally a bit confused that there was no object representing a library.

Say you want to unload a plugin library from your running system.  You
think your code has called unloadLibraryForClass() enough times for the
right classes, but for some reason it is not unloading.  Without changing
pluginlib, there is no way to ask pluginlib  why it is not unloading it (or
if it is trying and failing).

If there were a pluginlib::Library class, it could hand you the list of
instantiated classes with ref counts.  This is just for debugging purposes,
but then our customers are programmers.

Dave

On Thu, Feb 9, 2012 at 5:06 PM, Patrick Mihelich
<mihelich at willowgarage.com>wrote:

> On Thu, Feb 9, 2012 at 12:55 PM, Dirk Thomas <dthomas at willowgarage.com>wrote:
>
>>  While I like boost::shared_ptr, it is not always possible to use it
>>> nicely.
>>>
>>> In rviz I have plugin classes which are subclasses of QWidget (from Qt
>>> GUI library).  These objects are automatically deleted by Qt when their
>>> parent widgets are deleted.  I can be notified of their
>>> deletion by Qt, and call an "unload" or "decrement-reference-count"
>>> function, but it is not easy to use these QWidget pointers inside
>>> boost::shared_ptr without getting double-deletion crashes.
>>>
>>
>> That sounds like a very reasonable use case.
>> Automatically deleting and unloading is a nice feature but might not
>> always be desired.
>> Having the option to get a raw pointer (as before) and take care of
>> garbaging stuff manually would be great.
>
>
> I don't like this, but don't see a clearly better solution.
>
> So we have the problem that the shared_ptr is actually managing two
> resources - the lifetime of the object, and the lifetime of the loaded
> library (which must outlive all objects using it). The question is can we
> decouple those in a sane way. If we give up knowledge of the object
> lifetime, we also give up the ability to automatically manage the library
> lifetime.
>
> One slightly different approach:
>
> T* getInstance(const std::string& lookup_name, LibraryHandle& handle);
>
> Where the additional output LibraryHandle (could just be a shared_ptr
> typedef) represents the library lifetime, and decrements the lib ref count
> when it's destroyed. The user is responsible for making sure handle
> outlives the returned object. The advantages are that we don't have to
> expose [un]loadLibraryForClass() functions forever, and we make
> responsibility for the library lifetime explicit.
>
>  pluginlib::ClassLoader could have two interfaces, one which gives a
>>> shared_ptr and manages the reference count for the library itself, and
>>> another which gives a raw pointer and increments the ref
>>> count and also has a decrement-ref-count function.
>>>
>>
>> I propose the following names to make clear what the difference is (of
>> course with a more detailed doc-string):
>>
>>  boost::shared_ptr<T> getManagedInstance(const std::string& lookup_name)
>>
>>  T* getInstance(const std::string& lookup_name)
>>
>
> In any case I'd reverse the naming convention - have getInstance() return
> a shared_ptr and, say, getUnmanagedInstance() return T*. We should make the
> encouraged usage easier, and discourage the advanced/unsafe usage with a
> longer name.
>
> Cheers,
> Patrick
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120209/2922f87e/attachment-0004.html>