-
Notifications
You must be signed in to change notification settings - Fork 179
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
[MRG] feat: add PASS_CONTEXTVARS #582
[MRG] feat: add PASS_CONTEXTVARS #582
Conversation
Codecov Report
@@ Coverage Diff @@
## master #582 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 27 27
Lines 8426 8438 +12
=========================================
+ Hits 8426 8438 +12
|
ccd9ade
to
ac3a96b
Compare
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.
Some clarification would be appreciated for why make_target
exists.
d7578ad
to
ed1bc8e
Compare
Could you add something to the release notes as well? And add the new config variable to docs/reference/config.rst and utils.rst? |
ed1bc8e
to
46ce276
Compare
@scaramallion done |
er oops forgot release notes, one sec |
46ce276
to
3856212
Compare
3856212
to
05ff0e2
Compare
Reference issue
#578
Tasks
To expand on #578:
We'd like to be able to capture pynetdicom logs and filter for "all logs produced by associations in a particular calling thread". For example, if we're running a threaded storage scp we'd like to capture log output and filter for "all logs produced by a particular request thread".
Python stamps
LogRecord
s with athreadId
but pynetdicom spawns multiple threads over the course of handling an association. Some logs will be produced in the calling thread, some in the DUL thread(s) and some in the Association thread(s).Python does not have a way to define "thread groups" nor does it maintain a reference to the calling thread in spawned threads. We can hack around those things (e.g: grouping threads by
name
, subclassingThread
) but in the future, pynetdicom might not use threads for concurrency at all #527. We want a forward-looking solution that will work for concurrency models that might re-use threads. We'd also like to make minimal changes to pynetdicom, so avoiding things like e.g passing logger instances around or adding additional log handlers / filtering logic there.We think contextvars can achieve the goal here. We can attach logger filters that refer to
ContextVar
instances defined outside of pynetdicom and effectively hook into the logger calls inside of pynetdicom. To make this work, we need to pass along the current context to each thread spawned by pynetdicom. This is the default behavior in asyncio, so it should play nicely with a future implementation of #527.Let me know what you think!