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
Port syslog module to use module state #99127
Comments
|
Hmm, I think that I miss understood about syslog, I close ths issue as invalid. |
|
I've added some review comments to the PR, it seems to be on right path with some minor issues because the syslog extension changes process global state in the syslog library. Those issues IMHO can be easily fixed. |
Thanks I will take a look. |
|
Note that currently the syslog module already has the following characteristics:
We can't do much about the embedding case because the posix syslog API doesn't provide a way to get the current configuration (if any) such that you could restore it. For multiple interpreters, either we leave the current behavior or we try to make each interpreter independent. To do that, we have two options:
The "smarter" approach would require that the syslog module keep process-global state, along with a lock to protect that state. That would require something similar to what is discussed in https://discuss.python.org/t/20668 (and https://discuss.python.org/t/20663). For reference:
|
|
FWIW, for an implementation of mutli-phase init for a module, I would expect it to either deal with the sort of weird behavior syslog would have, or disallow use in multiple interpreters (at least in problematic cases). |
corona10 commentedNov 5, 2022
•
edited
While I check the @ericsnowcurrently 's checklist: https://github.com/ericsnowcurrently/multi-core-python/wiki/0-The-Plan
I found that the syslog module still uses the global variable for the following variables.
Both variables are declared as global variables since the original author assumes that in only one instance, only one syslog will exist.(one process one interpreter)
So I think that it's okay to move them into the module state if we consider the per-interpreter model.
The text was updated successfully, but these errors were encountered: