-
Notifications
You must be signed in to change notification settings - Fork 64
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: Run _async_no_progress_callback and _async_lag_callback in new t… #1521
Conversation
…hread. - revert std capture logger
Codecov ReportAttention:
... and 106 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
@@ -162,7 +162,7 @@ def _check_no_progress(self) -> None: | |||
|
|||
with self._lock: | |||
if self._should_call_no_progress_callback: | |||
self._async_no_progress_callback() | |||
threading.Thread(target=self._async_no_progress_callback, daemon=True).start() |
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.
daemon=True
False?
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.
Are you sure that Python doesn't require to call join()
? I heard that sometimes it may be needed (it wasn't Python). Stackoverflow says it's fine: https://stackoverflow.com/questions/49912013/python-what-if-we-call-thread-start-and-leave-it-without-join-or-close but just to be sure 😉
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.
With join the caller will wait and hold the lock indefinitely.
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.
All background jobs have daemon=True
, and I think that callbacks shouldn't block the exit of program.
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.
All background jobs have daemon=True, and I think that callbacks shouldn't block the exit of program.
We should probably ask someone from Product Team here :<
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.
With join the caller will wait and hold the lock indefinitely.
Yeah, I know. I was thinking about joining at the end of a script but I've looked for something like that and it's fine that we're not calling join at all.
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.
But let's proceed with this fix. This could be changed anytime.
@@ -162,7 +162,7 @@ def _check_no_progress(self) -> None: | |||
|
|||
with self._lock: | |||
if self._should_call_no_progress_callback: | |||
self._async_no_progress_callback() | |||
threading.Thread(target=self._async_no_progress_callback, daemon=True).start() |
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.
Are you sure that Python doesn't require to call join()
? I heard that sometimes it may be needed (it wasn't Python). Stackoverflow says it's fine: https://stackoverflow.com/questions/49912013/python-what-if-we-call-thread-start-and-leave-it-without-join-or-close but just to be sure 😉
…hread.
Before submitting checklist