[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
me.
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.
Shay
[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
[4]
https://github.com/roji/mono/commit/a2e54923bbd578e3fc8bdd95188b017648120de7
-------------- 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