-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
ENH: use constant f32 eps, not np.finfo() during import #15691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
NumPy docs for `np.finfo()` say not to call it during import (at module scope). It's a relatively expensive call, and it modifies the GIL state. Now we just hard-code it, because it is always the value anyway. This avoids touching the GIL at import, which helps avoid deadlocks in practice. Closes pandas-dev#14641.
@jzwinck can you confirm that this 'solves' the issue (not asking for a test in the codebase as might be tricky). just some verification. can you add a whatsnew note. |
Codecov Report
@@ Coverage Diff @@
## master #15691 +/- ##
==========================================
- Coverage 91.02% 91% -0.03%
==========================================
Files 143 143
Lines 49409 49409
==========================================
- Hits 44977 44967 -10
- Misses 4432 4442 +10
Continue to review full report at Codecov.
|
@jreback It "fixed" the hang on my system when I did I have added a note in whatsnew 0.20.0 now. As for testing, here is a C program which deadlocks before my patch and runs successfully after. Please note I believe it to be an erroneous program w.r.t. its multithreaded use of the Python C API--just to be clear this is not good code:
If you want, you could add this as a unit test, but I'm not sure exactly how it fits in to the project given the existing tests all seem to be written in Python, and apart from using CFFI there's probably no way to implement the above in Python. |
@jzwinck is there a way to do this directly using |
@jreback I don't think so, because it requires misusing (or failing to use)
the GIL, which no Python module short of FFI is going to facilitate.
…On Mar 15, 2017 23:43, "Jeff Reback" ***@***.***> wrote:
@jzwinck <https://github.com/jzwinck> is there a way to do this directly
using threading? IOW simulate importing *inside* the different threads.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15691 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABKRF_4hRWJzG66wGF1DC6PSWtbdo33Pks5rmAcJgaJpZM4Md5gS>
.
|
hmm, so how are that pure-python libraries that are simply doing imports failing? must be a race condition on the import itself in various threads.? |
No pure Python program had this bug. All the reports in the linked issue
are from Apache. My case was not Apache but was basically like the C test
program I posted here. This issue is all about importing Pandas in an
"embedded" Python interpreter.
…On Mar 15, 2017 23:57, "Jeff Reback" ***@***.***> wrote:
hmm, so how are that pure-python libraries that are simply doing imports
failing? must be a race condition on the import itself in various threads.?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15691 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABKRFwd0hdAYfxV_x7rkNKnuBbd-9O6Sks5rmAp_gaJpZM4Md5gS>
.
|
@jzwinck I c. ok will merge this and cross-fingers. thanks! |
NumPy docs for np.finfo() say not to call it during import (at module scope). It's a relatively expensive call, and it modifies the GIL state. Now we just hard-code it, because it is always the value anyway. This avoids touching the GIL at import, which helps avoid deadlocks in practice. closes pandas-dev#14641 Author: John Zwinck <[email protected]> Closes pandas-dev#15691 from jzwinck/patch-1 and squashes the following commits: dadb97c [John Zwinck] DOC: mention pandas-dev#14641 in 0.20.0 whatsnew e565230 [John Zwinck] ENH: use constant f32 eps, not np.finfo() during import
NumPy docs for np.finfo() say not to call it during import (at module scope). It's a relatively expensive call, and it modifies the GIL state. Now we just hard-code it, because it is always the value anyway. This avoids touching the GIL at import, which helps avoid deadlocks in practice. closes pandas-dev#14641 Author: John Zwinck <[email protected]> Closes pandas-dev#15691 from jzwinck/patch-1 and squashes the following commits: dadb97c [John Zwinck] DOC: mention pandas-dev#14641 in 0.20.0 whatsnew e565230 [John Zwinck] ENH: use constant f32 eps, not np.finfo() during import
NumPy docs for
np.finfo()
say not to call it during import (at module scope).It's a relatively expensive call, and it modifies the GIL state.
Now we just hard-code it, because it is always the value anyway.
This avoids touching the GIL at import, which helps avoid deadlocks in practice.
git diff upstream/master | flake8 --diff