Skip to content
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

Use ContextVar for current worker #5517

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gjoseph92
Copy link
Collaborator

Progress towards #5485.

This was surprisingly simple and actually seems to work. Not sure yet what it breaks.

I was pleasantly surprised to find that Tornado loop.add_callbacks, PeriodicCallbacks, etc. all play correctly with asyncio's built-in contextvar management. With that, just setting the contextvar during __init__ and start probably catches almost all cases, because all the long-running callbacks/coroutines (including comms) will inherit the context that's set when they're created. Where else should we add this as_current_worker decorator?

This gives me confidence we'll be able to use the same pattern for a single current client contextvar as mentioned in #5467 (comment).

cc @crusaderky @fjetter

Progress towards dask#5485.

This was surprisingly easy and actually seems to work. Not sure yet what it breaks.

I was pleasantly surprised to find that Tornado `loop.add_callback`s, `PeriodicCallback`s, etc. all play correctly with asyncio's [built-in contextvar management](https://www.python.org/dev/peps/pep-0567/#asyncio). With that, just setting the contextvar during `__init__` and `start` probably catches almost all cases, because all the long-running callbacks/coroutines (including comms) will inherit the context that's set when they're created. Where else should we add this `as_current_worker` decorator?

This gives me confidence we'll be able to use the same pattern for a single current client contextvar as mentioned in dask#5467 (comment).
"current_worker"
)

P = ParamSpec("P")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was recently burned by ParamSpec in that not all ecosystem libraries supported typing_extensions~=3.10 (in my case it was tensorflow). That may have improved in the last few months, but something to consider

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, trying to get ParamSpec working probably took 4x longer than actually implementing the content of this PR. I'm just really excited about it.

Since mypy doesn't even support it properly, there's not much value in it here yet. I had thought we could leave it around and remove the # type: ignores in the future, but I probably should just take it out before merging this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also excited about ParamSpec, and would like to use it for every decorator I see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replace worker use of threading.local() with ContextVar
2 participants