-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[R-package] limit number of threads used in tests and examples (fixes #5987) #5988
Conversation
We will revert this PR when the "global option" works? |
The parts of it about limiting number of threads in tests and examples, yes. The renaming of those two internal functions should be permanent, now that CRAN is complaining about them. |
Thanks @shiyu1994 ! I'll merge this and submit a new version to CRAN right now. Will |
Ok @shiyu1994 I just submitted on CRAN as v4.0.0.1. Please check your inbox. Thanks for your help! |
This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this. |
Fixes #5987.
This PR fixes the two issues that blocked the release of
{lightgbm}
v4.0.0 to CRAN a few days ago, documented in #5987..
-separated names to instead use_
Notes for Reviewers
Once this is approved, I'll push a release containing this PR to CRAN, as v4.0.0.1 (since a new submission requires a new release number, and to avoid creating a new actual LightGBM release of all other components).
Why is this touching so many lines?
I tried many variations of the idea from #5102 (comment), using a global option (specified in
R-package/tests/testthat.R
or at the tops of test files) to pass through a number of threads set inBooster$new()
. Unfortunately, they all resulted in segmentation faults (😬) fromtestthat
. Maybe related to some interplay between the fact that{testthat}
runs tests in sub-processes and the fact that session options are initialized when packages are loaded?I'm not sure. For now, to try to get a release up before the CRAN summer break, I think we should just hard-code
num_threads
to 2 in as many places as possible... can work out a more elegant solution later, when there isn't time pressure.Other references I consulted while trying to find a better solution