[Mono-bugs] [Bug 47659][Maj] Changed - Cannot create another AppDomain after a first one was created and unloaded.

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by vargaz@freemail.hu.

http://bugzilla.ximian.com/show_bug.cgi?id=47659

--- shadow/47659	2003-11-04 05:55:55.000000000 -0500
+++ shadow/47659.tmp.28815	2003-11-06 16:03:00.000000000 -0500
@@ -98,6 +98,33 @@
 
 
 ------- Additional Comments From JoergR@voelcker.com  2003-11-04 05:55 -------
 Created an attachment (id=5864)
 Test case
 
+
+------- Additional Comments From vargaz@freemail.hu  2003-11-06 16:02 -------
+This seems to be caused by some strange threading problem. Here is what
+happens:
+
+- mono_domain_unload will create a new thread to do the unloading
+- that thread calls mono_threads_abort_appdomain_threads
+- that function aborts one thread, then calls wait_for_tids for the
+  thread to exit
+- wait_for_tids calls WaitForMultipleObjects with a timeout of 1000, but
+  that function never returns, despite the timeout
+
+Here is what happens in WaitForMultipleObjects:
+
+- it calls _wapi_handle_ops_own on the thread handle, which calls
+  thread_own, which calls _wapi_timed_thread_join, which waits on
+  the thread's exit_cond variable.
+- that variable should be signalled by _wapi_timed_thread_exit,
+  but that function is stuck in thread_exit, which is stuck in
+  mono_mutex_lock (&thread_hash_mutex)
+
+That mutex is owned by the CreateThread function which started this
+whole stuff. That function releases the mutex eventually, but the
+mono_mutex_lock call in thread_exit does not seem to notice this.
+
+Creating the original thread suspended and resuming it immediately
+seems to make the problem go away. I checked in this workaround.