Fix closing asynchronous handler on Python 3.12.#207
Closed
jgoclawski wants to merge 1 commit intofluent:masterfrom
Closed
Fix closing asynchronous handler on Python 3.12.#207jgoclawski wants to merge 1 commit intofluent:masterfrom
jgoclawski wants to merge 1 commit intofluent:masterfrom
Conversation
Member
|
Would you check #208? I think it is simpler solution. |
Author
|
Thanks for taking the time to look into this! Closing in favour of #208. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consider the following example code:
On Python 3.12 this throws the following error:
On Python 3.12 starting a new thread during interpreter shutdown raises an exception. When using fluent-logger-python such exception can happen when a process configured fluent handler, but did not use it to emit any records, so there was no sender created and no thread active.
At the same time - handler is closed automatically with
atexithook (that's a good thing) by default, so on interpreter shutdown. Callinghandler.close()on a handler that did not emit any logs before, makes it create a sender, so that it can be immediately closed as well. But creating a sender also tries to create a thread - and this fails.This commit takes the following approach: use the default asyncsender when possible, but if it throws RuntimeError it means that the interpreter is shutting down - so let's use the synchronous sender instead, so that the main thread is used instead of spawning a new one.
BTW this is a common issue affecting every Python library that uses threads to send messages. Here's a similar issue for Sentry: getsentry/sentry-python#2299
and a fix: getsentry/sentry-python#2468