AppDomains and crash isolation conclusion

[Clinton Chau]

Hi all,



My findings have been confirmed by Juval Lowy, author of "Programming .NET
Components". Here's the transcript of email exchanges below.



Clinton



_____

From: Juval Lowy [mailto:***@idesign.net]
Sent: January 10, 2007 10:22 PM
To: ***@clearcanvas.ca
Subject: RE: Contacting IDesign



Yes, you are correct. In .NET 2.0, any unhandled exception takes down with
it the whole process. App domains therefore only provide for code-access
security isolation.



_____

From: Clinton Chau [mailto:***@clearcanvas.ca]
Sent: Wednesday, January 10, 2007 9:17 AM
To: ***@idesign.net
Subject: RE: Contacting IDesign



Hi Juval,



Thanks for replying. I've found Programming .NET Components to be a great
resource, and the same with your upcoming book on WCF, which I'm reading the
pre-press version of on Safari.

From Programming .NET Components, 2nd ed.

Re: pp 320-321, App Domains Versus Physical Processes

From the text in this section, it is implied that by using the .NET

AppDomain construct, it's possible to architect a system to be resilient
against crashes and faults. For example, in the case of a server-like
program that runs multiple independent applications, each within their own
AppDomain, we can achieve fault isolation, such that any one application
that crashes for whatever reason, will not take down all the other
applications and indeed, will not take down the host server.

From my experience, this does not appear to be the case, so I wanted some

clarification. When [you talk] about "fault isolation", [are you] only
talking about memory faults, since all managed code is checked for safety?
Furthermore, if this "fault isolation" encompasses only managed code, then
am I correct in assuming that any abnormal condition that triggers a
unmanaged C runtime abort(), for example, would also take down the entire
process, and along with it, all application threads, no matter what
AppDomain they were running in?



Thanks,

Clinton Chau