[Mono-devel-list] General impression about AppDomain.Unload() and finalizers

Jaroslaw Kowalski jaak at zd.com.pl
Sun Mar 21 03:11:03 EST 2004

Hi guys!

As you may know, I'm trying to get NAnt to run on Mono/Linux, but this
appears to be more difficult than I expected.

The root of all problems seems to be the AppDomain.Unload() & the

AppDomains are important because this is how NAnt integrates with external
tools (NUnit 2.x being the primary example). In addition, some NAnt
operations lead to creation and destruction of AppDomains. NAnt unloads each
domain after use with AppDomain.Unload(). Unfortunately (as Chris Brumme
described it in his blog -
http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx) this operation
is very difficult to implement and mono seems to have problems with it.
There are many problems: from deadlocks to some random exceptions. The
result is that it's close to impossible to run NAnt on Linux in a stable
manner today.

It's very difficult for me to debug this because this touches the internals
of garbage collector, which I know nothing of and producing reliable bug
reports is also difficult because of the non-determinism of GC.

Commenting out the body AppDomain.Unload() in
mcs/class/corlib/System/AppDomain.cs fixes all the problems. I'm aware that
this leaks some amount of memory, but for short-running applications like
NAnt this isn't a big problem.

With this in mind I'd like to propose a new (temporary) option to mono/mint:


which would cause a fast return from "mono_domain_unload()" in
"appdomain.c". This option would be off by default, but could be overriden
through the use of an environment variable, like "MONO_NO_UNLOAD".
As for the finalizers, they can be a problem too. How about a similar


that would disable the entire finalization mechanism (there's no guarantee
that finalizers will ever get called, anyway). There would be
"MONO_NO_FINALIZERS" environment variable for this purpose.

This would make many nanters and nuniters happy on Linux, at least for some

I can prepare a patch for this, if the idea gets any acceptance.


More information about the Mono-devel-list mailing list