Order of Service Constructors, Callbacks, and Destructors

Complete: 4

Order of Service Constructors

Services are constructed in the following order:

  1. Default services from cmsRun.cpp
  2. Forced services from cmsRun.cpp
  3. Services specified in the configuration

These are in the order specified in cmsRun.cpp and then in the configuration file. There are two exceptions to the order specified above:

  1. One can explicitly create services in the code independent of the categories above and combine them in with the services in the categories above. Explicitly created services can be created in any order, because the service infrastructure has no control of it.
  2. If the constructor of one service uses another service and this other service has not been created yet and it is listed in the configuration or as a default or forced service, then the second service will be constructed immediately when the first requests it. This "On Demand" creation overrides the order specified above. The purpose of "On Demand" creation is to correct problems where services depend on each other and are listed in the wrong order in the configuration file.

There is also the special case of services which are both in the default services list and the configuration file. In this case, the creation order is according to the default service list even though the parameters come from the configuration file.

Below is the service creation order in a cmsRun job. Warning: this order changes often and this list is likely to become out of date soon, but as of February 2007 the order was:

  1. JobReport (explicit creation)
  2. MessageLogger (default)
  3. InitRootHandlers (default)
  4. AdaptorConfig (default)
  5. EnableFloatingPointExceptions (default)
  6. UnixSignalService (default)
  7. JobReportService (forced, but it is not really created because JobReport exists already)
  8. SiteLocalConfigService (forced)
  9. Then all the Services in the configuration file
  10. ConstProductRegistry (explicit creation)
  11. TriggerNamesServices (explicit creation)

Order of Service Destructors

Destructors are called in reverse order of construction. This is always true in the current cmsRun.

There are a couple of potential loopholes that could cause problems with this destruction order in the future. First, if a service is explicitly created in the code and then explicitly "put" into the ServicesManager, then it's destruction order is based on when it is put into the ServicesManager because the ServicesManager cannot know when it was created. Second, the ServicesManager holds a shared_ptr to each service and uses that to manage their destruction. There is nothing preventing copies of these shared_ptr's from being made, which could cause problems if these they were still around when the destruction occurs.

Order of Activity Registry Callbacks

The entry functions registered in the ActivityRegistry are called either in the same order as the constructors or the reverse order as specified below:

Signal Order
PostBeginJob forward
PostEndJob reverse
JobFailure reverse
PreSource forward
PostSource reverse
PreProcessEvent forward
PostProcessEvent reverse
PreProcessPath forward
PostProcessPath reverse
PreModuleConstruction forward
PostModuleConstruction reverse
PreModuleBeginJob forward
PostModuleBeginJob reverse
PreModuleEndJob forward
PostModuleEndJob reverse
PreModule forward
PostModule reverse
PreSourceConstruction forward
PostSourceConstruction reverse

There are two cases where this ordering can fail.

  1. The first case is the same as for the destructor where the service is explicitly created in the code. One can get the order correct in this case if one carefully uses the copySlotsFrom function in the ActivityRegistry.
  2. The second case occurs when the service is built "On Demand". In the constructor of the dependent service, the calls to register callbacks to the ActivityRegistry should come AFTER any calls to other services that could result in "On Demand" service creation. If and only if they are BEFORE and "On Demand" creation occurs, then the callback in the ActivityRegistry will be in the wrong order for the offending service.

There are objects that register slots with the ActivityRegistry that I do not consider services because they are not put into the ServicesManager and not accessed as a normal Service. Both the ActivityRegistry and CMS.EventProcessor allow one access to add callbacks to the signals in ActivityRegistry. The order of these callbacks is not specified although it is reproducible. These could be ordered as the Services if they are carefully added using copySlotsFrom function in the ActivityRegistry.

Three final random comments. First, the three services currently explicitly created do not have any callbacks registered with the ActivityRegistry. Second, the objects that are not services that have callbacks registered with the ActivityRegistry are from the "Vis" related packages. Third, the code in ServiceManager.cc that handles the kConfigurationOverrides case does not properly handle the callbacks in ActivityRegistry (this case is not used anywhere, I just noticed it but did not have time to fix it, my preferred solution to fix it would be to delete this case entirely).

Review Status

Editor/Reviewer and date Comments
Main.wdd - 16 Feb 2007 page author

Responsible: Main.wdd
Last reviewed by:

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2007-07-03 - JennyWilliams



 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback