Codecov Report

Merging#692 intomaster willdecrease coverage by0.21%.
The diff coverage is65%.

@@            Coverage Diff             @@##           master     #692      +/-   ##==========================================- Coverage    76.9%   76.69%   -0.22%==========================================  Files          63       64       +1       Lines        5798     5925     +127       Branches      950      977      +27     ==========================================+ Hits         4459     4544      +85- Misses       1025     1052      +27- Partials      314      329      +15

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update5ee234a...4eff81e. Read thecomment docs.

This is duplicate for the#532. There are several PR that are exists more than half of a year, and still not approved.

@amos402 please review#532 and let me know your feedback.@dmitriyse that code in your PR is really hard to review, it is beyond my understanding of Python/CLR internals. I still give preference to@dmitriyse PR but@amos402 if there is anything extra beyond#532 in your PR, please let us know.
I'm planning to review your PRs within 2 weeks and then merge if no issues are found.

@denfromufa, ok. I will update those PRs in this week.

@denfromufa@dmitriyse I reviewed the#532 roughly, it create a thread for decreasing the reference of python objects, it would slow down Python if you get GIL oftenly.
But my solusion it's no need for a new python thread or .net thread. You can event use it that Python didn't compile withWITH_THREAD macro.
Because of Python's GIL, I suggest we should avoid use multithread on it. btw. I'm going to remove the PyEval_InitThreads call on Initialize for my next version.

Note from python document

Note
When only the main thread exists, no GIL operations are needed. This is a common situation (most Python programs do not use threads), and the lock operations slow the interpreter down a bit. Therefore, the lock is not created initially. This situation is equivalent to having acquired the lock: when there is only a single thread, all object accesses are safe. Therefore, when this function initializes the global interpreter lock, it also acquires it. Before the Python _thread module creates a new thread, knowing that either it has the lock or the lock hasn’t been created yet, it calls PyEval_InitThreads(). When this call returns, it is guaranteed that the lock has been created and that the calling thread has acquired it.

It is not safe to call this function when it is unknown which thread (if any) currently has the global interpreter lock.

This function is not available when thread support is disabled at compile time.

I agree with@amos402 Py_AddPendingCall can give some benefits and my approach can be improved for Python 3.1+.
But I cannot agree right now with WeakReferences and GC.ReRegisterForFinalize approach. I need some research.

We are looking for different directions: single and multi threaded environment. Dedicated thread was the only approach that succesfully solve memory leak in the my multithreaded application.

@amos402 Please check this#541 bug on your branch, ensure that your finalizers approach also elliminates memory leak.

@dmitriyse I try two cases, it seems no problems exceptPythonException was leak by original code. I fixed it on my branch.

can be improved for Python 3.1+
Why 3.1 specificed?
WeakReferences only use for query garbages, it's no need for running time.
If you want to avoid callGC.ReRegisterForFinalize, you can just make a interface for getting all python object pointer. But I think it's not necessary, garbages will put into garbage queue, with the queue's reference, they can be resurrected.

@amos402 some git conflicts with master branch now.

This PR causes appveyor CI to get stuck for one hour on each build.

This PR causes appveyor CI to get stuck for one hour on each build.

😥I still can't figure out why it just crash on 3.7 on Linux

Already fixed it. It crash on 3.7 because I changed PYTHONMALLOC in test case.

I added ref count check on debug mode, it should be helpful for finding the bugs like this

PyStrings1=newPyString("test_string");// s2 steal a reference from s1PyStrings2=newPyString(s1.Handle);