[Mono-dev] Order problem in runtime shutdown flow

Shay Rojansky roji at roji.org
Sun Nov 18 20:50:53 UTC 2012

Hi everyone.

It seems there's a small problem with the way the runtime shuts down at the
moment: the thread pool (and apparently other resources) are shut down
before the ProcessExit signal is fired. This is the cause for the NLog bug
described here[1], since NLog relies on the threadpool being available in
ProcessExit (works on Microsoft but not mono). To my mind this is a bug,
although oddly enough there's a runtime test[2] that appears to imply that
it may be normal?

I've submitted this pull request[3] on github which has a test[4] that
reproduces the problem, and a proposed patch which is probably insufficient
since my first time in the runtime. The general idea is this:

* mono_runtime_shutdown(), which runs the ProcessExit event code is
executed from mini_cleanup(), which is a pretty late step (after we
shutdown the pool and other resources in thread_manage()).
* The same thing happens in System_Environment_Exit(), which again shuts
down the thread pool before calling mono_runtime_quit() (which eventually
triggers the mono_runtime_shutdown()).
* My working patch moves mono_runtime_shutdown() and
mono_domain_finalizers() out of mini_cleanup() and into thread_manage() and
System_Environment_Exit(), right before we shut down the thread pool and
other stuff.

Somebody who actually understands everything in there should take a look at
this... For one thing, the according to the comment in mini.c,
mono_domain_finalize() also seems like it should be called earlier, but
going so (next to mono_runtime_shutdown) triggered a segmentation fault for

Also, my patch duplicates code the two function calls, although other calls
are already duplicated. It seems that a small cleanup/refactor could help
eliminate this duplication, both across thread_manage() and
System_Environment_Exit() and across mini and the interpreter (which
doesn't trigger the ProcessExit event?) I'd be glad to go deeper into this
if people think it's good/necessary.


[1] http://nlog-project.org/2011/10/30/using-nlog-with-mono.html
[2] https://github.com/mono/mono/blob/master/mono/tests/bug-438454.cs
[3] https://github.com/mono/mono/pull/505
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121118/8897a8d3/attachment.html>

More information about the Mono-devel-list mailing list