Scenario:
C ++ is encapsulated as COM and C # For calling. The call may be in the thread.
When the application exits, part of C # is automatically cleared, and some threads may not be completely stopped.
COM is also releasing memory.
At this time, it will crash if you are careful.
Conflict point:
1. Multiple Threads repeat ReleaseComObject,
2. C # A thread is still in use, and another thread or main thread goes to ReleaseComObject.
3. ReleaseComObject has been performed, and c # is still in use by a thread.
The most depressing thing is:
=
This Try-Catch is useless. If an exception occurs, it will still die.
The solution is as follows:
1. To solve the problem of repeated ReleaseComObject in multiple threads, determine the principle of "who creates Release". If not, leave it to Release when the App exits.
2. The resource has been Release and is still in use.
Check found that a thread sleep for 100 milliseconds. When the App exits, it can do a lot of things within Ms.
In addition, I don't know if there is a good way to determine whether the COM object exists or not and whether it can be called safely.
3. The resources being used, and the other thread goes to Release and follows the first principle for execution.
4. The method of loop in the thread should be as small as possible, so that the UI and quick brakes can be updated in time.
5. The thread factory should be as simple and clear as possible. The cost of complexity is the pain of writing and maintenance.
I tried to change a few places and found that there was still a problem. The out-of-control multithreading meets COM, which is really difficult.