Conversation
Generally though, sometimes our use of OMP_NUM_THREADS makes other systems sad. It's unfortunately somewhat difficult to turn off. A common approach is that people set `OMP_NUM_THREADS=""` but this doesn't properly unset things. I'm curious if an approach like this would be helpful. There might be a cleaner way to do this, and this might be a bad idea. Please feel free to reject. It was just easy to put this up as a PR.
Not anytime soon but seems like a positive change to me. |
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 27 files ± 0 27 suites ±0 11h 28m 55s ⏱️ - 2m 51s For more details on these failures, see this check. Results for commit b735ba0. ± Comparison against base commit fd3722d. ♻️ This comment has been updated with latest results. |
|
No objections. It appears to not be working, though. The test is failing (linter is also off) |
…um-threads-off
jacobtomlinson
left a comment
There was a problem hiding this comment.
This doesn't seem to actually unset things. If I set the env var and run pytest the test fails.
$ OMP_NUM_THREADS=1 pytest -k test_omp_num_threads_off
====== 1 failed, 15 skipped, 4020 deselected in 3.52s ======|
I think this won't be relevant anymore if we confirm #9081. |
Generally though, sometimes our use of OMP_NUM_THREADS makes other systems sad. It's unfortunately somewhat difficult to turn off. A common approach is that people set
OMP_NUM_THREADS=""but this doesn't properly unset things.I'm curious if an approach like this would be helpful.
There might be a cleaner way to do this, and this might be a bad idea. Please feel free to reject. It was just easy to put this up as a PR.
@ntabris would something like this make your life easier? @fjetter is this not dumb?