One of the great things that I heard at the preconference session was the new way that hosts can interact with the Common Language Runtime in version 2.0.
SQL Server 2005 is one of the new hosts for the CLR. Besides general Win32 processes, ASP.NET is the best known host that we had before SQL2005 came along. A host uses the COM interface ICorRuntimeHost to register itself as a host for the runtime. Mscoree.dll is loaded into its process space and the hosts’s soul is sold to the CLR. The CLR is in full control of everything inside it.
This loading of the runtime by host has changed for .NET 2.0. The bottom line (before I go off into some gory details) is that the host can now take control of some tasks of the runtime. Here’s how that goes:
The runtime has a new interface called ICLRRuntimeHost. This interface is similar to ICorRuntimeHost. The host gets a reference to this interface by calling CorBindToCurrentRuntime or CorBindToRuntimeEx. The cool stuff happens with the method SetHostControl. This method allows the host to provide a IHostControl reference pointing to some object in the host.
When the runtime starts it will call IHostControl::GetHostManager and pass in interface IIDs to determine whether the host supports these. If the host does, the runtime allows the host to take care of the services offered by the interface. The services the host can manage are:
- Thread pooling
- IO completion
- Assemblies (assembly and type loading)
- Cross-assembly calls
- Garbage collection (!)
This is exactly what SQL Server does: it takes control of some of the services it doesn’t want to give to the CLR. That includes the garbage collection. SQL Server 2005 is very picky when it comes to resource management. It needs to keep on top of the management of resources, so bad managed code does not tear SQL Server down.
I guess that these new features were built into the new runtime because SQL Server required it. Good for us. It offers a lot of new possibilities for host builders. Not that I am one 😉