On 11/14/2015 05:47 AM, Claudio Valderrama C. wrote: >> -----Original Message----- >> From: Alex Peshkoff [mailto:peshk...@mail.ru] >> Sent: Viernes, 13 de Noviembre de 2015 7:25 >> >> On 11/13/2015 01:17 PM, Vlad Khorsun wrote: >>> interface LoadedModuleInfo : Versioned >>> { >>> const string getModuleName(); >>> ... >>> } >> It should be RefCounted to be saved in module, all the rest is OK and >> looks much better than use of ModuleInitialization in >> FB_PLUGIN_ENTRY_POINT >> Moreover - due to presence of versioning schema it can be >> added at any >> moment when gets needed >> >>> interface PluginModule : Versioned >>> { >>> void doClean(); >>> void setModuleInfo(LoadedModuleInfo info); >>> } >>> >>> Plugin implementation could ignore passed info, store >> interface pointer >>> for future use, or query all necessary info and release >> interface pointer. > At risk of becoming an uninvited guest or a troll... > > can I ask naively why the thing needs to be so complex and now it has to be > RefCounted, too?
It's related to lifetime of interface instance. Lifetime may be unlimited, controlled by lifetime of some other object to which this interface is related (in our case lifetime of configuration interface may be equal to the lifetime of loaded module), controlled by single "dispose" call or controlled by reference counter. Use of permanent interface is not an option here - configuration for module may change during server lifetime, and creating new and new permanent instances means memory leak. For later analysis I take into an account that most of modules do not need configuration at all - at least modules of all existing plugins do not. Therefore making ModuleConfig lifetime equal to loaded module lifetime almost always means keeping unneeded interface for a lo-o-o-o-ong time in most cases. Disposable interface may be used, but it means that a lot of modules that do not need config must put "moduleConfig->dispose();" call in initialization routine. For RefCounted interface we do not have that problems - plugin manager creates it, passes to the plugin module and releases after it. Plugin module that does not need configuration does nothing with it. If plugin module needs config info, it adds it's reference to the module and releases it when config is not needed. > Is this a kind of functionality that will be used only by > the core developers? In this case, it can be as complex as one wishes if > this makes FB more obscure to the casual readers of the source code. > ;-) I do not understand why do you think that use of reference counted interfaces is so complex. People do work with ole2 interfaces for decades. > However, if it's planned that other people will use those declarations to > build their own plugins, it should be understandable. At this point, > sincerely, I can barely understand what's being discussed. Certainly, all > this design seems very far away from early ideas people had two years ago. There were _so_ many ideas... > I > see discussions about details but I can't find a basic architecture > description, maybe I'm missing some obvious documents? There is doc/README.plugins.html but it's very far from ideal. Like unfortunately a lot of our documentation... > Sorry for getting into a terrritory that's not mine. You are welcome :) ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
