[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.
Sat, 30 Oct 2004 19:43:22 -0400 (EDT)
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 firstname.lastname@example.org.
--- 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 email@example.com 2004-10-30 16:15 -------
+------- Additional Comments From firstname.lastname@example.org 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.