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:[EMAIL PROTECTED] Sent: January 10, 2007 10:22 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 9:17 AM To: [EMAIL PROTECTED] 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. My question was also sent to [EMAIL PROTECTED], so you can ignore it if you see it again: >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
_______________________________________________ dev mailing list [email protected] http://clearcanvas.ca/mailman/listinfo/dev_clearcanvas.ca
