Another internal thread I thought i’d share…
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">I want to
sandbox objects of certain types that will be running in my process so that if
anything in these objects crashes for any reason, code in the other objects
continue to execute. I’m assuming AppDomains will be my solution
here. First, is that a good assumption?
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Second, if these objects are calling
into unmanaged code that is creating threads that could potentially throw
exceptions, will AppDomains help me here?
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">A: (again from a senior guy on our
If code has UnmanagedCodePermission,
SkipVerificationPermission, FullTrust, or a number of other highly privileged
permissions, it has the ability to toast the entire process.
If code only has Execute or similar low-trust
permissions, it cannot toast the entire process. However, there it can
still cause a denial of service by spawning many threads that consume the CPU,
or allocating lots of memory to swamp the GC, or blocking inside a Finalize
method so the finalizer queue grows without limits.
allow you to separate the managed state of different applications so that they
cannot write over each other without performing unsafe highly privileged operations.
AppDomains allow you to shut down and unload individual applications without disturbing
the other applications in the process. Currently AppDomains are a weak boundary with respect to
security. Over time, we’ll be looking at strengthening that security
Threads travel between AppDomains. If you call between AppDomains and an
exception is thrown, that exception will be marshaled back across the remoting