.NET hosting the world's application domain and thread
Keywords: hosting host public language runtime application domain assembly thread Managed Host CLR (Common language runtime) Appdomain Assembly Thread
First, the primer .NET framework provides a new computing platform, gives the consistent object-oriented programming environment, solves the problems existing in the original system platform of security, version control, and provides the public language run (CLR). An efficient, secure program executive environment is also managed (also known as controlled, managed). In this similar virtual machine environment, how do our programs run, how to "host"? How does this hosting world interconnected with non-hosting world?
Second, how to enter the "hosting" world, we must understand that so far, there is no "pure natural" .NET execution environment (not excluding the next .NET chip in the future), the so-called hosted environment (CLR ) Need to run on the currently stored system. To enter the hosted .NET world, there is a need for a host (Host) program to prepare the enforcement environment for the .NET managed code to run - the foundation CLR to load .NET world. On the current Windows system, you can take this heavy-to-have 3-class memory program: 1. Shell (usually Explorer), provide startup .NET programs from the user desktop, create a process, start this process to establish CLR2, browser host (Internet Explorer) handling the .NET code execution from the web download. 3. Server hosts (such as IIS Auxiliary Process ASPNET_WP.EXE) Before performing any managed code, the host must first load and initialize the public language run. Suppose one .NET executor (PRJ1.exe) starts from shell, the operating system will build a process first, which is the host process. The loaded program file includes a Stub that is typically (created this .NET application compiler) in performing configuration information and execution code, this stub is actually a 6-byte local code: JMP _COREXEMAIN And _corexemain is exported from the external library Mscoree.dll, which is introduced by the prj1.exe, so the operating system will load Mscoree.dll (enter the .NET world's sequence song), correct the actual position when _Corexemain is actually positioned. Mscoree.dll is actually a COM component library. After calling _corexemain, starting to initialize the CLR, and check the CLR related data structure of Prj1.exe, determine the entry of the execution .NET managed code. The host calls .NET supports API CORBINDTORUNTIMEEX to load CLR, and according to the configuration initialization of the CLR, such as garbage collection strategy, etc., because different hosts faced, the application needs, a service host with ordinary workstation host "garbage The recovery "(GC) mechanism is obviously different, so the parameters when the CLR starts to start the CLR. The host is loaded is a component library file Mscoreee.dll that conforms to the COM specification, which is the CLR, typically existing in the operating system directory (facilitated loading). For more understanding of Mscoree.dll, it is recommended to see the header file Mscoreee.h in the frameworksdk directory. Mscoree.dll gives the host by providing a starting CLR, such as the IcorRuntimeHost interface can be used to configure all aspects of the running library (such as garbage recycling) to load it into the process or registered additional events, where the start / stop method can make The host controls the Survival of the CLR in the host process. In fact, we can use CorbindtoruntimeEx to write to implement your own host, regarding the implementation of the .NET host can be used as a topic, here, give several URLs for your reference. Http://www.codeproject.com/dotnet/simpleclrost.asphttp://www.elitevb.com/content/print.aspx?contentId=95Http://msdn.microsoft.com/library/default.asp?url= /Library/en-us/cpgenref/html/grfuncorbindtoruntimeex.asp
At this point, we understand that the CLR-omnipotent virtual machine is "parasitic" in a DLL form in a non-hosting world! The so-called hosting world actually refers to the controlled environment established in MSCoree.dll. No wonder the user who is proficient in VCL says that the CLR is the MS version of the VCL! Third, the application domain (APPDOMAIN) and the thread in the domain have declared entry .NET World once the CLR is loaded and initialized. The CLR detects all types referenced by the function before performing the first inlet function (usually compiled), and applies for an internal data structure from the stack from the heap, managing all references through this data structure CLR Access to the type of type, this is the fundamental mechanism of the hosted. Each type of method has an entry for retrieval and reference, saving the code location of the method in an entry. When a function is performed for the first time, the JITCompiler function belonging to the CLR service is called, which is responsible for obtaining the code according to the entry, and all IL code is verified after compiling cost machine code. Each object in .NET exists regardless of the size, there is a unique Hash code in the current CLR, which can be distinguished as a similar database key field to distinguish each object, .NET base class Object. getHashcode () Help get the Hash code for the current object. If this method function is called later, these native code will be called directly. This process is the so-called "instant compilation". Each manual method of hosting is compiled into the local code before calling the CLR, and then handed over to the operating system scheduling CPU execution. Understand the details of the managed code at runtime, can help us understand the nature of domain and threads and their relationships. The so-called IL verification mainly performs safety inspection, which is generally verified according to the managed code metadata and the CLR rule, such as whether a variable is initialized, calling the parameters carried when a function is correct, the method calls always returns, etc. . Typically, IL verification will throw VerificationException anomalies when you encounter it as unsafe, prevent the code to continue. Initialization, the CLR establishes the first AppDomain, which is the default application domain, and execute the entry code in this domain. In terms of concept, the application domain is the "application in which the application in which the application executes in the world" is the container of multiple assemblies to execute or referenced (an application domain is definitely loaded) . Don't understand the concept of processes, the application domain exists in the CLR, while the CLR belongs to the host process, and the application domain is the concept of different levels. However, .NET designer is an application domain in the process of operating system, making Appdomain an executive unit, and interposed with each other. In general, the following figure can help the relationship between the host, the CLR, the application domain. Figure one
To manage loaded assemblies, each application domain has its own configuration information and storage area, reference, execution border, and an important thing is to have its own security policy. Security Policy Storage In evidence, all assemblies within the same appDomain share these resources and security instructions. As mentioned earlier, according to these configurations, the metadata and evidence verification code in the program, make sure the application domain's code will not "cross", do not destroy the objects of the other domain, and ensure that there will be no C world Terrible invalid, the risk of error pointers. Typically, only one application domain's .NET program is implemented similar to traditional unmanaged world. After the default application domain ends, the process ends, and the CLR is uninstalled like other DLLs. However, if there are multiple domains, then the situation is complex - at least, the CLR must wait until all the application domains are over, may be released in accordance with DLL rules. In addition, unlike communication between the processes, there can be low interactions between application domains in the same operating system process, but the separation characteristics of the restricted application domain cannot be done directly in one application domain. The domain instance object (the object is closely related to the assembly, the application domain is closely related, the CLR will "take tube" them to ensure that the application domain code is implemented. There are two cases in the domain of objects: If the domain reference object itself is transmitted, the object must support serialization (implement interface system.iserializable), which will be serialized when crossing the domain objects Reach the target domain after deactivation, at this time, the assembly of the object definition is loaded due to deserialization. If it is an object that passes the reference type, the boundary of the destination domain (the domain that needs to reference the object, the container domain of this object) creates an agent of an instance object, and the original object still exists, "Enron" is affected by the referenced The domain, but the example object agent (that is, the package wrapper) knows how to communicate with this object, this agent is a method of scheduling an instance object through the service provided by the CLR. If the object is not supported by serialization or the type of support reference, or if the assembly defined by the load object is failed (the assembly cannot be positioned or the application domain security is not loaded), it will result in an exception. It is usually indicated that this is an illegal cross-domain object reference operation. Although all application domains may exist in the same operating system process, it still causes some losses due to the security isolation of the application domain. If there is no need, avoid doing so as much as possible. The application domain is the lightweight sub-process of the .NET CLR world, but the thread is the basic unit of the operating system allocated processor time. The threads are scheduled by operating system according to a certain priority rule, and there is a need to keep the thread execution context. The context is to make the thread seamlessly continue to perform the required information in the host process space of the thread, including the CPU register group and stack of threads. The application domain can also create multiple sub-threads outside the main thread, .NET's Thread and ThreadPool classes provide packaging of threads for the operating system, greatly simplifying the use of threads. These threads belong to the current process when we create additional sub-threads in a primary thread in an application domain. From an operating system perspective, thread does not matter, the thread in the process created by a .NET program is actually the same process, which also causes the thread to not only exist of an application domain. In, it can be in multiple application domains during thread (but only one particular domain) is performed as needed.
Application domains and threads do not have one-to-one relationship, one thread can span multiple application domains, and an application domain can create multiple threads by loading an assembly class instance object. The application domain method call, object resolution, IL verification execution, etc. are controlled by the CLR, so the application domain can be mutually blocked. However, the thread belongs to the operating system scheduling, and there is no burden on the application domain, and it can be quickly switched to be executed by the system. When there is a need for thread to access an object from one domain or an object of an object of the other domain, it is actually a domain communication issue. Therefore, an ObjectHandle type agent will be created in the current domain (see the discussion above), then use the ObjectHandle's Member method unwrap to get a reference to the target object, and perform the target code by reference. Since all managed code execution actually passes the CLR inspection, the CLR will determine that the domain operation is the same (host) process, thus allowing the current thread code to execute, perform the method code of the object of the target domain, thus The "crossing" domain is implemented. In fact, if an object domain interpolation / reference domain does not belong to the same process, communication between the domains uses .NET Remotting technology instead of jump directly through the current thread code to another. If you leave an angle of the CLR, from the perspective of the operating system, it is purely the thread scheduling inside the normal process. The "consumption" between the domain is complete because the "God" of the CLR this .NET World is executed in the inspection code (but must), the specific details are roughly: because all managed objects, the methods and the like are in CLR There is an entry that enables an object, and it will automatically find the entry by the CLR, which is managed by the CLR, and then determines the execution of the local code. The CLR determines which domain belongs to the current entry, assigns a private storage and resource of the domain to the current thread (thread utilizes static method Appdomain.currentDomain to get the current application domain object). In fact, involving span-domain references and executions, interactions between application domains, whether multiple domains of the same process or different processes, or even different machine domains, communication usually treats according to the distribution of domains Since the CLR can distinguish whether the code to be jumped is as the same process or the same machine, the cross-domain thread scheduling of the same process actually enables the thread to jump to the target domain after the boundary agent passes through the CLR, and performs the corresponding native Code. We can further understand the relationship between threaded homologs in conjunction with the following picture: Note that Thread2 in the figure "Cross" main Appdomain and multiple subappdomain during the life. Thread3 The entire life cycle is only available in appdomain1. AppDomain1 has 3 threads running, Thread1 and Thread2 are transferred to AppDomain2 execution, and between THREAD1 and Thread2 execute the code of reference objects through the proxy, switching the thread to appdomain2. Thread2 initially executed from the default domain, cross the default domain, appdomain1, and appdomain2 during execution.
There may also affect the code execution stream - exception. When the application domain needs to be uninstalled, all threads of the application domain will be notified by the CLR, and the CLR will force a ThreadAbortexception exception in the current domain thread, forcing them to exit the application. On the other hand, the CLR checks all proxy objects in other domains involved in this domain, setting them to invalid. In the future, anything I want to implement other domain objects through these proxy will trigger an AppdomainunloyDexception. The unloading of the application domain can be issued by its own or own subordinates, or may be issued by the code from other domains (such as being created after a subdomain in a primary application domain). If the application domain cannot be uninstalled due to various reasons, it will generate an exception of CannotunloadAppdomainexception. If the application domain itself (including the sub-thread created by the application domain), the uninstall command is issued, then a new thread is created to uninstall the application domain, and the resulting exception is captured by the CLR; if it is another The code in the domain issues an uninstall command, and the exception will be transferred to the thread that issues the uninstall command. Clearly understand the abnormal glow route, you can ensure that we write safe and reliable applications.
Fourth, Appdomain Society In fact, we see, .NET's hosted environment CLR is built by putting a COM DLL file Mscoree.dll into the current operating system process. Hosting the world's execution object provides metadata and IL code and security evidence, etc. In the CLR memory, all managed code is compiled by JIT, and because all objects of the CLR are "managed" to ensure similar process environments for AppDomain. The execution separation is performed, and the CLR can block any unsafe access according to the boundary of the application domain. The CLR also tracks the management trust thread, threads can be moved through the communication functionality between the domains in multiple application domains. The process and thread belong to the operating system scheduling execution unit, but the application domain belongs to the execution logic unit of .NET, the code execution of the application domain is implemented by "hosting", and the separation of data accesses between domain data. Typically, our .NET applications only need a default application domain, but there are also some situations that consider building other application domains may be better: 1. The assembly that needs to be isolated, such as some particularly easy to crash. The code can consider running in a specific AppDomain2, different security levels, if you need to securely execute the boundaries of the security execution, you can consider the code of different security levels separately in a certain set of security information. AppDomain3, from performance, some assessments may consume a lot of resources, although there is basically no resource consumption vulnerability in the hosted environment, there is always a specific time access, which will consider the creation of a large number of resources. Separate Appdomain, the unloading of AppDomain after the resource consumption exceeds the critical point, and adapts to the system operation requirements. 4, running simultaneously with different versions of the same app set. This is a big problem in the COM era. Now through appdomain, you can achieve two additional assemblies that have different versions in a process can achieve good compatibility. 5, dynamically load some programs. You can use some unused assemblies to dynamically load, (for efficiency), the assembly that is often used, can be dynamically loaded, or even loaded into the application domain. 6. Shared assembly, improve the efficiency of .NET. For example, we use objects such as System.Object System.Int32 often need multiple application domains, resulting in waste, to reduce resource usage, including these commonly used .NET classes Mscorlib.dll will The way, the CLR will maintain a special loader so that this assembly will only be unloaded when the process is interrupted, thereby increasing speed, reducing the waste of resources such as memory. V. Reference This article roughly discusses the implementation mechanism of the .NET CLR hosting, and how the assembly is loaded into the application domain execution, threads, etc., at the execution below, trying to help readers understand the execution of managed computing environment code execution situation. However, there is no detailed explanation of the system details of the .NET framework, even if you do not provide analysis, please refer to the following information: 1, ". Net, please refer to the following information. Framework Design (Revised Edition) "Jeffrey Richter / Li Jianzhong Translation Tsinghua University Press. 2, ". NET core technology - principle and architecture" Liu Xiaohua compiled electronic industrial publishing House 3, MSDN .NET Framework SDK
