CLR Hosting Managers


The COM interfaces in the hosting API that the host and the CLR use to communicate with each other are grouped into what are called hosting managers. A hosting manager is nothing more than a convenient way to categorize a set of interfaces that work together to provide a logical grouping of functionality.

For example, a host can use the hosting interfaces to provide a set of allocation primitives through which the CLR will direct requests to allocate memory. This manager is referred to as the memory manager and consists of the interfaces IHostMemoryManager and IHostMalloc. As another example, consider the manager that lets a host control various aspects of how assemblies are loaded in a process. Four interfaces are involved in providing this customization: IHostAssemblyManager, IHostAssemblyStore, ICLRAssemblyIdentityManager, and ICLRAssemblyReferenceList. These interfaces are grouped into what is called the assembly loading manager.

Both of the managers in the preceding examples consist of multiple interfaces, as many managers are. In these cases, one of the interfaces is designated the primary interface. The main role of the primary interface (apart from implementing some of the functionality of the manager) is to participate in the discovery process, or the steps that are taken to identify which managers the host and the CLR implement. (More on this in the section entitled "Hosting Manager Discovery" later in this chapter.)

A few important points about the hosting managers are worth highlighting. First, some managers are implemented by the CLR, some are implemented by the host, and some are split, in that both the host and the CLR implement portions of the manager that complement each other. The hosting interfaces follow a naming convention that makes it easy to tell whether a particular interface is implemented by the CLR or by the host. All interfaces that are implemented by the CLR start with ICLR, whereas those implemented by the host start with IHost. Second, the factoring of the API into a set of managers gives the host the flexibility to customize some, but not all, aspects of the CLR. Every manager is optional; that is, the host implements only those managers that support the customizations they require. However, if you decide to implement a particular manager, you must implement all of it. You cannot implement just those methods you choose and delegate the rest to the CLR defaults, for example. The fact that hosts get to pick only those customizations that are specific to their needs is what makes the CLR so adaptable to a variety of scenarios.

Table 2-2 briefly describes all the managers in the CLR hosting API. (The primary interface for each manager is shown in boldface.)

Table 2-2. The CLR Hosting API Managers

Manager

Purpose

Interfaces in the Manager

assembly loading

Used by hosts to customize various aspects of the assembly loading process.

IHostAssemblyManager

IHostAssemblyStore

ICLRAssemblyReferenceList

ICLRAssemblyIdentityManager

host protection

Enables enforcement of a host-specific programming model.

ICLRHostProtectionManager

failure policy

Enables the host to customize the way failure conditions are handled by the CLR.

ICLRPolicyManager

IHostPolicyManager

memory

Enables the host to provide a set of allocation primitives through which the host will allocate memory. The CLR uses these primitives instead of their Microsoft Win32 equivalents.

IHostMemoryManager

IHostMalloc

ICLRMemoryNotificationCallback

threading

Enables the host to provide primitives to create and manipulate tasks (an abstract notion of a "unit of execution"). The CLR uses these primitives instead of their Win32 equivalents. The threading manager also enables a host to trap all calls into and out of the CLR.

IHostTaskManager

ICLRTaskManager

IHostTask

ICLRTask

thread pool manager

Enables the host to provide a custom implementation of the thread pool used by the CLR.

IHostThreadPoolManager

synchronization

Enables the host to provide a set of synchronization primitives such as events and semaphores. The CLR will use these primitives instead of their Win32 equivalents.

IHostSyncManager

ICLRSyncManager

IHostCriticalSection

IHostManualEvent

IHostAutoEvent

IHostSemaphore

I/O completion

Enables the host to plug in a custom implementation to handle overlapped input/output (I/O).

IHostIoCompletionManager

ICLRIoCompletionManager

garbage collection

Enables a host to force a collection, obtain statistics about recent collections, and receive notifications when collections begin and end. Unlike the other managers, the interfaces in the Garbage Collection Manager are discovered independently; hence, there is no primary interface.

IHostGCManager[1]

ICLRGCManager

debugging

Enables a host to customize how debugging works in its particular scenario.

ICLRDebugManager

CLR events

Enables a host to receive information about various events happening in the CLR, such as the unloading of an application domain.

ICLROnEventManager

IActionOnCLREvent[2]


[1] Neither of the interfaces in the garbage collection manager can be considered a primary interface. These two interfaces are independent and don't need to be used together, so one isn't obtained from the other.

[2] IActionOnCLREvent is implemented by the host. As such, it should probably have been named IHostActionOn-CLREvent to follow the naming convention that indicates whether the implementation for a given interface is provided by the CLR or by the host.

Given this background, let's begin our tour of the hosting API by looking at how to initialize and load the CLR in a process.



    Customizing the Microsoft  .NET Framework Common Language Runtime
    Customizing the Microsoft .NET Framework Common Language Runtime
    ISBN: 735619883
    EAN: N/A
    Year: 2005
    Pages: 119

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net