diff --git a/mozilla/xpcom/doc/xpcom-code-faq.html b/mozilla/xpcom/doc/xpcom-code-faq.html index 397d1e699eb..ed74a0a9f3b 100644 --- a/mozilla/xpcom/doc/xpcom-code-faq.html +++ b/mozilla/xpcom/doc/xpcom-code-faq.html @@ -33,19 +33,30 @@ Is there any restriction on which static class I should call first
No restrictions. You can call any function from the static classes nsComponentManager and nsServiceManager. XPCOM will do the right -thing to initialize itself at both places.
+thing to initialize itself at both places. +

Autoregistration() can happen only after Init_XPCOM() is called since +the registy might be required by SelfRegister() functions of the dlls and +it is only in Init_XPCOM() do we create register the RegistryFactory() +with the ComponentManager.

What is the order of creation of the ServiceManager, ComponentManager and Registry

Init_XPCOM() -
    create the global component manager -
    create the global registry and register as service -with global service manager -
    create the global component manager and register -as service with the global service manager -

Now the hard problem is when to trigger Init_XPCOM() There are two static +

+
  • +create the global component manager
    • + +
  • +create the global component manager and register as service with the global +service manager
    • + +
  • +RegisterFactory(...RegistryFactory...)  Register the RegistryFactory() +with the component manager so that new registry objects can be created.
    • +
    +Now the hard problem is when to trigger Init_XPCOM() There are two static objects nsComponentManager and nsServiceManager. Any function in either of them can be called first. Today nsServiceManager::GetService() is the first one that gets called. All the members of the static nsServiceManager @@ -55,6 +66,17 @@ to get to the global component manager. Hence if we trigger Init_XPCOM() from both NS_GetGlobalComponentManager() and NS_GetGlobalServiceManager() we will be safe.
    +

    +Is there a global Registry being maintained

    + +
    No. The nsIRegistry is designed to be lightweight access to +the registry. Consumers who need to access the registry should use the +component manager to create the their own registry access object. This +is required because the open() call is supported by the nsIRegistry() and +if we maintain a global registry arbitrating which registry file is opened +is going to be a major headach. +

    The ProgID for the registry will be component://netscape/registry

    +