[Mono-bugs] [Bug 66915][Maj] Changed - Calling back on a delegate passed to native code through p/invoke on a different thread causes a crash.

[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 daniel_l_christensen@yahoo.com.

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

--- shadow/66915	2004-10-30 16:15:39.000000000 -0400
+++ shadow/66915.tmp.22406	2004-10-30 19:43:22.000000000 -0400
@@ -62,6 +62,27 @@
 The problem with automatically registering threads with the runtime is
 that nobody unregisters them, so the per-thread data structures
 allocated by the runtime are leaked.
 
 ------- Additional Comments From vargaz@gmail.com  2004-10-30 16:15 -------
 -> wontfix
+
+------- Additional Comments From daniel_l_christensen@yahoo.com  2004-10-30 19:43 -------
+In the simple example that I provided there is a simple and obvious
+place for me to put a mono_thread_detach. As usual, real life,
+however, is more complex. In my real app a worker thread is created to
+service asynchronous actions. As various actions come down on the main
+thread they are dispatched to the worker thread. The worker thread
+then notifies the main thread when the action is complete. 
+
+Under a normal execution path, when the main thread terminates, the
+cleanup on the main thread will shutdown the worker thread.
+Unfortunately under mono, after calling thread attach, the app does
+not exit and the cleanup sequence is not initiated because the worker
+thread is blocking the app from exiting.
+
+I guess that the bottom line is that, yeah, I can come up with hacks
+to make this work on Mono. But over and over I am having to come up
+with hacks to solve problems in Mono that just work in .NET. The whole
+philosophy behind p/invoke was supposed to be so that you could
+consume pre-existing native code without having to modify the existing
+code to know anything about the managed code sitting above it.