-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Fix SignalConnector._has_already_handler check for callable type #10483
Fix SignalConnector._has_already_handler check for callable type #10483
Conversation
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.
LGTM. Can you add a test to avoid regressions? Can be a simple unit-test. _has_already_handler
can be made static for it.
Done. |
Co-authored-by: Adrian Wälchli <[email protected]>
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.
LGTM !
Interesting, wasn't aware of this PR, but I have also one here #10611 where I changed the
Is the check for callable necessary? Which way is the correct way to check this, anyone knows? :) |
I guess the callable is not necessary. What should be the behavior if the value is |
Good point, I think we should respect it and not add a handler in that case too? |
Codecov Report
@@ Coverage Diff @@
## master #10483 +/- ##
=========================================
+ Coverage 43% 88% +45%
=========================================
Files 177 177
Lines 16520 16506 -14
=========================================
+ Hits 7034 14534 +7500
+ Misses 9486 1972 -7514 |
…10483) Co-authored-by: Adrian Wälchli <[email protected]> Co-authored-by: thomas chaton <[email protected]> Co-authored-by: Carlos Mocholi <[email protected]>
…10483) Co-authored-by: Adrian Wälchli <[email protected]> Co-authored-by: thomas chaton <[email protected]> Co-authored-by: Carlos Mocholi <[email protected]>
What does this PR do?
Fixes an issue where a user's registered SIGTERM signal handler is overwritten by
SignalConnector.register_signal_handlers
. One case in which this happens is when a method of a class instance is registered. That is:The current check
isinstance(signal.getsignal(signal.SIGTERM), FunctionType)
evaluates to false, thus overwriting it.No related issue. This was discussed over slack.
Does your PR introduce any breaking changes? If yes, please list them.
Before submitting
PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:
Did you have fun?
Make sure you had fun coding 🙃