Re: unloading plugins (i.e. shared objects) nearly impossible!
Chris Uzdavinis wrote:
Here's the kicker: suppose I load a plugin. That plugin
creates, for me, a boost::any() holding some really simple,
plain, vanilla data type. Say, just for kicks, it is a
double** with a value of zero. And say that the plugin
passes me back, by value, just a straight up-and-up copy of
that boost::any, and I keep it around in my main program.
But I don't even bother to look inside it. I don't query
it, I don't do *anything* to it.
And now say I unload the plugin.
I think you're overlooking the fact that "unloading the
plugin" is more than just unbinding a shared library from your
application. Every object that it created must also be
destroyed in the process of unloading the plugin, and the main
application must completely forget about them. Otherwise you
have only partially unloaded the plugin!
I think you're missing his point. He doesn't have any objects
created by the plugin. He only has copies of them. And
conceptually, that should be OK. After all, if one of the
functions in plugin returns an int, I don't expect to have to
ensure that all copies of that int are destructed before I
unload the plugin.
It is the basic difference between value and entity. A value
gets copied, and the copy is fully independant of the orignal
object. Or should be. And normally, this works, because if my
code outside of the plugin must know how to copy and to delete
the object independantly of the plugin in order to use it.
This is not a new development, nor a problem that the C++
community has recently cast upon itself.
It's fairly unusual for values to depend on hidden polymorphic
objects. Coplien's letter/envelope idiom comes to mind, but
that's about it. And the problem only manifests itself if a
value object is polymorphic, and the root never creates an
object of the actual, hidden type.
It's just another manifestation of the book-keeping problem
that programmers have had for years. I do not see it any
different than the effort you must spend in keeping track of
which pointers need to be delete-ed, which need to be
delete[]-ed, which need to be free()-ed, and which need
nothing done to them at all. You simply cannot mix those
pointers carelessly and expect a program to run (correctly)
because you cannot know how to manage your memory. Similarly,
you cannot allow objects in your application to depend on
"unloadable" parts of your applicaion after it has been
unloaded. The objects with this dependency must disappear
along with the code they use or else the design of your plugin
is broken.
The problem is that while it is established practice to document
memory management policy, it is rare to see such hidden code
dependencies documented. I'll bet (without looking), for
example, that boost::any doesn't document that you cannot unload
the plugin which created the actual contained type, and Boost
generally does a much better job at documentation than most.
Smart pointers can help solve the problem for pointers, as
they can keep a "deleter" with the pointer, which knows
exactly what needs to be done for this particular pointer. I
think the same concept will work with your plugin problem.
Your plugin would hold a smart-pointer for each object it
allocates and remember them all. When it gives a reference to
the host application, it only provides a weak_pointer which
refers to the object that the plugin holds. Weak pointers are
observers which go to null when the subject is destroyed, and
when the plugin is unloaded its smart pointers would destroy
its objects, and the host application's weak pointers would
become null. Of course, the host application must be prepared
to deal with null pointers, but programmers have dealt with
that problem for years.
The problem is that he's not dealing with pointers, but with
value objects. He doesn't want a pointer to the object, he
wants a copy of it. And it is the destructor of the copy which
fails.
(BTW: I'm not sure that boost::weak_ptr's are the solution here.
To use a weak_ptr, you still have to get a shared_ptr to the
object. So you also need some mechanism for preventing
unloading the object if one of those shared_ptr is still in
existance.)
There are other strategies, perhaps more efficient, but this
is a pretty simple and obvious one.
For every difficult problem, there is a simple and obvious
solution... which is wrong:-). (Boost smart pointers can
definitly help here, and make the implementation of a solution a
lot easier. But using them still doesn't mean that you can skip
the design work.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]