18.03.2013 19:11, Adriano dos Santos Fernandes wrote:
...
>>> And this is what I saw it's required to support, but do you think the
>>> current code allows it?
>> As far as I know - yes, it does.
> I'm not sure I understand you. More below.
Let me try to explain it
>>>>> , as the engines will call a yvalve function
>>>>> (fb_get_master) who cannot be guessed from what library it must be
>>>>> called. IMO, IMaster should being passed as parameters, and not like
>>>>> current.
>>>> PluginEntrypoint* startModule;
>>>> if (module->findSymbol(STRINGIZE(FB_PLUGIN_ENTRY_POINT),
>>>> startModule))
>>>> {
>>>> startModule(masterInterface);
>>>>
>>>> Removed some code to make it visible better that IMaster is passed here
>>>> as a parameter to plugin module at startup. If you prefer another form
>>>> ("not like current"), please suggest.
>>> Usage of CachedMasterInterface in jrd.cpp seems correct.
>>>
>>> But what about this code?
>>>
>>> IMaster* CachedMasterInterface::getMasterInterface()
>>> {
>>> if (!cached)
>>> {
>>> cached = fb_get_master_interface();
>>> }
>>> return cached;
>>> }
>>>
>>> If you have 3.0 and 3.1 engines loaded in memory, each one correctly
>>> loaded by different client/y-valve libraries, how do you think when this
>>> code is called inside the engine, it will get the correct IMaster?
>> Yes. It will get IMaster from yvalve which loaded an engine.
>
> If you have:
> /opt/app/fb3.0/lib/fbclient.so loads /opt/app/fb3.0/lib/fbengine30.so
> /opt/app/fb3.1/lib/fbclient.so loads /opt/app/fb3.1/lib/fbengine31.so
>
> Do you think fb_get_master_interface() called from fbengine30.so will
> call /opt/app/fb3.0/lib/fbclient.so and /opt/app/fb3.1/lib/fbengine31.so
> will call /opt/app/fb3.1/lib/fbclient.so?
>
> If true, that's news for me that things just works automatically as
> there. And what about Windows DLLs? And others posix (HP-UX, AIX) platforms?
It is true and there is no magic. When fbclient.so loads fbengineXX.so
(or any other plugin), it passed IMaster pointer into plugin entrypoint.
Plugin cached it using CachedMasterInterface descendant (MasterInterfacePtr)
and always used this pointer. Therefore fbengine30.so will call fbclient.so
from /opt/app/fb3.0/lib and fbengine31.so will call fbclient.so from
/opt/app/fb3.1/lib (in your example).
>>> Many places calls MasterInterfacePtr, PluginManagerInterfacePtr and
>>> others that will not work correct.
>> The question is what is called correct. In plugins there will always be
>> present cached IMaster. In external code (currently it's only remote
>> server if I'm not missing something) fb_get_master_interface() from the
>> library loaded at startup time top resolve external references will be
>> used. On my mind that's correct.
> I'm not sure I understand you in relate to doubts expressed above.
Again, MasterInterfacePtr will return cached IMaster pointer passed by
plugin manager which loads current plugin module.
If we speak not about plugin module (host application for example), it
will use that IMaster pointer which was obtained from direct call of
fb_get_master_interface() of particular plugin manager loaded by such module.
If application is statically linked with fbclient, OS loader will find
and load some and resolve fb_get_master_interface() from it.
If application dynamically loads fbclient, it (app) will manually resolve
fb_get_master_interface() and obtain IMaster from it.
Of course, application can load few different plugin managers (fbclient's)
and use every one with corresponding IMaster pointer.
...
Regards,
Vlad
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
