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
Continuation of PR #7280, fixing lifetime of TBB task_scheduler_handle #7294
Conversation
As title. Minor refactor of pycc support testing into numba.tests.support to save code duplication.
2b09d2d
to
96edef4
Compare
96edef4 fails for the TBB build with https://dev.azure.com/numba/numba/_build/results?buildId=9489&view=logs&j=064bd7ca-23e4-5078-9cb6-8968eb13bf19&t=30a4dffd-4ede-53d2-ca39-79d23392ba79&l=409 (segfault)
|
792e2d4 contains @PokhodenkoSA / @Hardcode84 patch for the issue. |
792e2d4 failed once with :
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patch. I have a few comments.
if (!tbb::finalize(tsh, std::nothrow)) | ||
{ | ||
tbb::task_scheduler_handle::release(tsh); | ||
puts("Unable to join threads to shut down before fork(). " | ||
"This can break multithreading in child processes.\n"); | ||
} | ||
tsh_was_initialized = false; | ||
need_reinit_after_fork = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked that these changes are needed to make the new test pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks.
# incorrect permissions, compilers that don't work for the above | ||
print(e) | ||
print('BROKEN_COMPILERS') | ||
sys.exit(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this return a different exit code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The self.run_cmd
checks for exit code 0 and raises assertion error if it is not. What I was attempting to do here is differentiate between "This test cannot be run because of some compiler setup problem" and "The compiler setup was fine and the test can be run, but is has failed". The test uses a non-zero exit code which results in the assertion error to signal the latter and a zero exit code with a special token assigned to the BROKEN_COMPILERS
variable for the former. Should the BROKEN_COMPILERS
condition occur, the test sets a self.skipTest()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As agreed in OOB conversion, there are too many ways for the compilation to fail. We will allow the test to be a little fragile (may accidentally skip). Later we will look into ways to make sure the test is not skipped on systems that we have tight control and can guarantee the test must work.
This needs to go through the build farm a couple of times to see if the test time out happens on machines with more resources. |
Buildfarm ID: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patch!
The test maybe fragile but it is not worth stressing over accidentally skipping it for this rare problem.
Continuation of PR #7280, fixing lifetime of TBB task_scheduler_handle
As title.