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

[Patrick Mihelich]

On Fri, Feb 10, 2012 at 10:46 AM, Dirk Thomas <dthomas at willowgarage.com>wrote:

> On 10.02.2012 04:32, Lorenz Mösenlechner wrote:
>
>> I actually think you still can use a shared pointer in that case.
>> shared_ptr has a overloaded constructor that takes an explicit delete
>> functor. When the reference count reaches zero, instead of
>> calling delete, the functor is called.
>>
>> I'm not sure if that helps here, but I think this is at least a
>> possibility to consider. Instead of returning a normal pointer where the
>> user has to calll decrement-reference-count manually, it should
>> be possible to just have a share_ptr deleter that calls the
>> decrement-ref-count function.
>>
>
> Technically yes, that would be possible.
> It would make the method signature much easier.
> We use the deleter for the createInstance() method which performs deleting
> the instance as well as decrementing reference count.
>

The real issue here is that Qt releases the object simply by calling delete
on the raw pointer. Even if you have a shared_ptr to the object, Qt
releasing it does not automatically decrement the reference count. So
you're actually requiring the user to hang on to the shared_ptr, then
explicitly release it when Qt notifies him (by some other mechanism) that
the object pointed to by the shared_ptr has been deleted. Which is
unintuitive, to say the least.

The only way I see to make this work is to do something like the "weak
without shared"
hack<http://www.boost.org/doc/libs/1_48_0/libs/smart_ptr/sp_techniques.html#weak_without_shared>.
You require the plugin to hold a shared_ptr to itself, with a deleter that
only decrements the library reference count. So when Qt deletes the object,
the shared_ptr is destroyed and the library ref count decremented. An
interesting benefit is that the unloading code could maintain weak_ptr's to
the unmanaged instances, to verify that it's actually safe to unload the
library.

But that's pretty convoluted, and requires the plugin author to inject some
messiness into his interface. Maybe it could be wrapped into a reasonable
API, but would require some work.

But would it be obvious for a user that a method like:
>  boost::shared_ptr<T> createUnmanagedInstance(const std::string&
> lookup_name)
> does NOT delete the instance when it runs out of scope?
> The API doc can state that fact clearly, but I think the return value
> gives the user a wrong impression how it is intended to be used.
>

I agree. Function signatures should be as self-explanatory as possible,
because users often won't read the fine print.

I was trying to get at the same point in questioning

T* createUnmanagedInstace(const std::string& lookup_name)

because there's no hint from the signature that this should be paired with
a later call to unloadLibraryForClass(). With load/unload, at least it's
clear from the names that the methods are paired.

Cheers,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120210/02544d1d/attachment-0004.html>