Actually, the LoaderOptimization flag controls how the JIT-compiled code for types is handled. But it won't affect the observable nature of having types loaded separately into each appdomain from the standpoint of a developer and their expectations with respect to the scope of static fields. The storage for static fields is always allocated on a per-appdomain basis. Using the LoaderOptimization attribute does not change that. It does change whether the code for types is JIT-compiled once per-process or once per-appdomain. Code that accesses statics is therefore JIT-compiled differently based on that setting (per-process code has to use a level of indirection to "find" and access the static variables for the appdomain the code is running in at any moment in time; while code that access statics and compiler per-appdomain can be JITed with a direct reference to the variable).
-Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Greg Reinacker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 03, 2002 5:09 PM Subject: Re: [ADVANCED-DOTNET] Singleton pattern > > Don't you automatically get one > > instance of a static class in each app-domain? > > This behavior depends on the LoaderOptimization setting, which is set > when an AppDomain is created (either at AppDomain.CreateDomain, or > CorBindToRuntimeHost). > > Greg Reinacker > Reinacker & Associates, Inc. > http://www.rassoc.com > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Shawn > Wildermuth > Sent: Sunday, June 02, 2002 12:24 PM > To: [EMAIL PROTECTED] > Subject: Re: Singleton pattern > > > I've been using static classes for singleton's. Is this a bad approach? > Are static constructor's unreliable? Don't you automatically get one > instance of a static class in each app-domain? Maybe that's the > issue... > > Thanks, > > Shawn Wildermuth > [EMAIL PROTECTED] > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED]] On Behalf Of Noam Arbel > > Sent: Saturday, June 01, 2002 12:39 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Singleton pattern > > > > > > I think it is usefull to understand when SuppressFinalize() > > should be used. If you look at code like this: > > > > public class UseResource > > { > > public void OpenResource() > > { > > // open a resource for use > > } > > > > public void UseResource() > > { > > // Do some stuff with the resource > > } > > > > public void CloseResource() > > { > > // close the resource > > SuppressFinalize(); // <== make sure Finalize is not called > > } > > > > ~UseResource() > > { > > // close the resource > > } > > > > > > A good coder will open the resource, use it multiple times > > and call the > > CloseResource() at the end (hopefully in a finally block). > > This will call the SuppressFinalize() letting the GC know > > that cleanup has been done. > > > > But if the user did not call the CloseResource explicitly, it > > will get closed through the destructor and not left dangling. > > > > As to the public constructor on the Singelton class, it does > > look strange. > > > > Noam > > > > You can read messages from the Advanced DOTNET archive, > > unsubscribe from Advanced DOTNET, or subscribe to other > > DevelopMentor lists at http://discuss.develop.com. > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
