Application Domains

.NET has introduced the concept of an Application Domain, or AppDomain. These are like lightweight processes, meaning that you can have more than one inside a native operating system (i.e., Win32) process.

AppDomains provide a halfway house between threads and full processes. Processes are useful because they are completely isolated from one another; each has its own address space, and it isn't easy for one process to write to (and possibly corrupt) the address space of another. The problem with processes is that they are heavyweight—there's a lot of data associated with a running process, and creating them and then swapping between them in a multitasking system is expensive in time and resources. This is especially true under Windows, but less of a problem under Unix.

Threads are good because they don't have all the baggage associated with a process, and this makes them much more lightweight. Creating and maintaining threads is much less of a drain on system resources, and multitasking between them is much quicker. There's a problem, though, in that threads share many parts of their parent process, which leads to the many well-known problems concerned with unwanted (and unanticipated) interactions between threads.

An AppDomain, which may contain one or more assemblies, is completely isolated from any other AppDomains running in the same process, as shown in Figure 1.5, so there's no sharing of memory or data. In fact, the separation is so complete that another AppDomain running in the same process is treated in exactly the same way as one residing on another machine; the same .NET remoting mechanisms are used to communicate between them.

Local AppEkmain

Remote AppDnmnin

Operating System Pfoccss

Figure 1.5: AppDomains.

Figure 1.5: AppDomains.

0 0

Post a comment