Re: [boost] [extension] Concatenating factory_map objects

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2008-07-07 22:42:42

Robert,

> I'm developing a plugin system and I will be loading several DLLs.
> Basically, as far as I know, this means having one factory_map per DLL
> (on Windows).

This depends on how you want to use the factory_maps. Do you want to close
the shared libraries that you aren't using? If not, just use the same
factory_map for every shared library. Unless you have a LOT of separate
shared libraries, this is usually a good solution (if you have a lot, you
may not want the unused libraries taking up RAM).

If you do want to close unused shared libraries, it's a bit trickier. I had
some code that did this, but have let it languish because it didn't cover a
number of special cases. Here is more or less how it worked:

   - Create a counted_factory_map instead of a factory_map. Internally, a
   counted_factory_map contains a separate map and shared_library object for
   each shared library.
   - Whenever you ask it to add a constructor for a class T, it instead adds
   a constructor for a class counted<T> (which is a derived class of T), which
   increments and decrements a counter whenever it is created or destroyed.
   - There is a function in the shared library that can be called to see how
   many objects are currently live from the given shared library.
   - You can call a function on the counted_factory_map to do garbage
   collection - ie, close shared libraries with no live objects.

The reasons this code is not currently used in Extension:

   - It requires a duplicate of almost every class in Extension - a counted
   version and a non-counted version.
   - The counted versions have very high coupling - whereas the uncounted
   versions of shared_library and factory_map are very loosely coupled. It also
   makes it impossible to use parameter_map in its current form.
   - It requires, in the common case, the use of mutexes to protect the
   counters. This requires linking in the Thread library.
   - It only works if all you are doing in a shared library is constructing
   objects using counted_factory. If you take a reference to anything else in a
   shared library, you risk having a dangling reference when all of the
   counted<T> objects are destroyed. Note that this can be alleviated by using
   a separate shared_library instance if you want to do anything besides
   populate a counted_factory_map, since a shared library is only closed when
   all shared_library instances referencing it are destroyed (it is also
   possible to force a shared library to remain open until program termination
   - by passing false as the second parameter to the shared_library
   constructor).

There were a few other special cases that broke it as well - but I can't
remember what they were right now.

I can update that code if people are interested. I certainly wouldn't mind
suggestions about how to avoid some of the problems that I listed, or a
different way of handling this sort of "garbage collection" of unused shared
libraries.

Thanks!

Jeremy Pack