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

add a Handle::current() for getting access to TLS Runtime #2040

Merged
merged 10 commits into from
Jan 6, 2020

Conversation

bluejekyll
Copy link
Member

@bluejekyll bluejekyll commented Dec 29, 2019

Motivation

Get a Runtime::Handle to the current thread local storage Runtime components.

Solution

This adds a blocking::Spawner reference to ThreadContext. With that we then have access to all the components needed for a Handle::current. This will panic if components haven't been registered that are required.

@bluejekyll bluejekyll closed this Dec 29, 2019
@bluejekyll bluejekyll reopened this Dec 29, 2019
@@ -60,6 +60,8 @@ cfg_not_blocking_impl! {
where
F: FnOnce() -> R,
{
let ctx = crate::runtime::context::ThreadContext::clone_current();
Copy link
Member Author

Choose a reason for hiding this comment

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

I don't see why this isn't necessary and wasn't here before...

Copy link
Member

@carllerche carllerche Jan 2, 2020

Choose a reason for hiding this comment

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

Currently, since BlockingPool::enter only sets the context for the blocking pool spawner, the no-op version doesn't need to do anything. This fn is only here to make feature flag code easier.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok. Would you like me to remove this?

Copy link
Member

Choose a reason for hiding this comment

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

I think removing it would be best.

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed.

}
}
let ctx = crate::runtime::context::ThreadContext::clone_current();
let _e = ctx.with_blocking_spawner(self.clone()).enter();
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm confused about why the Cell with a raw pointer was necessary here, when Spawner has an internal Arc.

So I simplified this to focus on just using that fact. I'm sure I'm missing something. The Drop for ThreadContext along with enter performs the same revert that was happening with the Reset before.

feature = "io-std",
feature = "rt-threaded",
))]
pub(crate) fn with_blocking_spawner(
Copy link
Member

Choose a reason for hiding this comment

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

I think this can be replaced w/ the cfg_blocking_impl macro (here). It cannot go around fn defs, so you would split it out to another impl block:

cfg_blocking_impl! {
    impl ThreadContext {
        pub(crate) fn with_blocking_spawner(....) { ... }
    }
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, done.

pub(crate) fn io_handle() -> crate::runtime::io::Handle {
#[cfg(any(not(feature = "io-driver"), loom))]
Copy link
Member

Choose a reason for hiding this comment

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

Could you elaborate on why this change was made?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh. I think it was failing CI with a unused warning? Though I can try reverting it.

Copy link
Member

Choose a reason for hiding this comment

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

Should the fn io_handle be scoped w/ a cfg then? The fns below have had their cfg bits removed. I'd be interested in seeing the error.

Copy link
Member Author

Choose a reason for hiding this comment

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

So the way that it's written right now, the field is not optional, it gets swapped out for () when these features aren't enabled (apparently). Here's the error with a default cargo check with those changed reverted::

error[E0308]: match arms have incompatible types
   --> tokio/src/runtime/context.rs:105:21
    |
103 |           CONTEXT.with(|ctx| match *ctx.borrow() {
    |  ____________________________-
104 | |             Some(ref ctx) => ctx.io_handle.clone(),
    | |                              --------------------- this is found to be of type `()`
105 | |             None => None,
    | |                     ^^^^ expected (), found enum `std::option::Option`
106 | |         })
    | |_________- `match` arms have incompatible types
    |
    = note: expected type `()`
               found type `std::option::Option<_>`

Copy link
Member

Choose a reason for hiding this comment

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

Ah! What if you sub None for Default::default()?

That said, it is curious that io_handle() is required even when the io-driver feature isn't enabled.

Copy link
Member Author

Choose a reason for hiding this comment

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

This stems from the way the Handle::Current works, which asks for all the components of ThreadContext, where Handle has all of these, so cfging off the io_handle function will spider out for a lot of other changes. Maybe Default::default() will work...

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, that works.

@carllerche
Copy link
Member

This looks good to me. I added some minor inline comments.

@bluejekyll
Copy link
Member Author

ok, @carllerche , I think I cleaned up what could be. Let me know if you want me to take care of anything else.

Verified

This commit was signed with the committer’s verified signature. The key has expired.
carllerche Carl Lerche
@carllerche
Copy link
Member

I merged master & resolved the conflict.

@bluejekyll
Copy link
Member Author

Thanks! I didn't notice we ended up with a conflict.

@carllerche
Copy link
Member

I've been merging a lot of PRs

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

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

Thanks for pushing this through 👍

@bluejekyll
Copy link
Member Author

No problem. It's really benefiting from all the work that was done on ThreadContext.

Thanks for managing all of this!

@carllerche carllerche merged commit 0193df3 into tokio-rs:master Jan 6, 2020
@bluejekyll bluejekyll deleted the handle-current branch January 8, 2020 00:05
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.

None yet

2 participants