On 13/10/2011 22:04, My Th wrote:
> C , 2011-10-13 23:13 +0300, My Th rakstīja:
>> C , 2011-10-13 13:53 -0400, David Lonie rakstīja:
>>
>> As I understand, plugins do not keep track of their instances. So when
>> you create new one with MakeNewInstance() the reference to old one is
>> lost (Doesn't it lead to memory leaks?).
>>
>> So if we add a static member variable to the OBForceFieldUFF class which
>> keeps pointers to the live instances, then we can use that in destructor
>> to reset plugin map pointers to the original instance. Something like in
>> the attached patch for OBForceFieldUFF.
>>
>> I'm not sure if this is the best solution, but it seems like something
>> that is working. Hope it helps.
>
> Other solution would be to change the constructor so that pointers in
> plugin map are not overwritten if the instance with the same ID already
> exists.
>
> That basically leaves open the same question I made yesterday - what to
> do when the last instance of the plugin sub-type is destroyed?
I had been thinking previously about ways of updating the plugin system.
It could do with improvements in three areas:
a) the need to load all the dynamic libraries at startup
b) a proper factory class for instances, rather than a macro
c) not using a single global instance when deployed
Your recent discussion has been related to c). Most plugins use only the
single instance, which is a bit unsafe, even without multiple threads. I
wonder whether a cleaner, more radical design would be better. A global
instance of a plugin is made when the it is loaded, as at present, but
FindType(id) would always returns a shared_ptr to a new instance. The
shared_ptr means this instance would be copyable and automatically
deleted without the user having to remember. The always-new instances
would be a move towards thread safety. The user would have more
flexibility but is insulated from inadvertent damage because the global
instance is not accessible to him.
The code of each plugin type would not change, but it would require a
small change to the code that used the the plugin, potentially breaking
user code.
e.g. old code
Forcefield* pFF = FindForceField("UFF");
if(pFF) {
...
}
The user would need to replace "Forcefield*" by "shared_ptr<Forcefield>"
or "auto". I'm not sure how acceptable this is, and I haven't tested
these ideas.
Chris
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
