Rust: Remove TLS dependency from async/await

Created on 24 Jul 2019  路  10Comments  路  Source: rust-lang/rust

Futures currently have a dependency on TLS for storing a pointer toContext<'_>.
https://github.com/rust-lang/rust/blob/master/src/libstd/future.rs#L116

This makes usage in no_std environments quite difficult.

A-async-await AsyncAwait-Triaged C-enhancement T-libs

Most helpful comment

Duplicate of rustasync/team#42

Not sure if you were suggesting this, but I don't think we should be using other repo's issues to track changes to rustc.

All 10 comments

I would like to tackle this since it's blocking a personal project.

cc/ @cramertj @eddyb @nikomatsakis @Zoxc

Duplicate of rustasync/team#42

There's also some additional background discussion on the rust-internals discourse.

Duplicate of rustasync/team#42

Not sure if you were suggesting this, but I don't think we should be using other repo's issues to track changes to rustc.

I mean, nor do I but that is where most of the existing discussion is. It may be worth closing the other thread to try and avoid splitting the discussion over two issues on separate repos.

I'm running into this as well. You can work around it and get things working using a hack akin to this https://github.com/SunriseOS/core-futures-tls but it requires overriding libcore for every crate that needs #![feature(async_await)] which makes it difficult to do in library crates. TLS-free async fns would be cool.

(I'm sure this workaround is well-known but just posting for future readers that might come across this issue)

@cavedweller

I would like to tackle this since it's blocking a personal project.

Are you still working on this? I don't have much experience with the Rust compiler, but maybe there is still a way I can help?

Not actively working on it, but i'm interested in giving it a go again, it's a gnarly one. Just moved cross-country and only now just returning to a somewhat stable life pattern.

That being said, if you want to do it and have the time, give it a go please!!

On September 15, 2019 6:30:39 AM EDT, Philipp Oppermann notifications@github.com wrote:

@cavedweller

I would like to tackle this since it's blocking a personal project.

Are you still working on this? I don't have much experience with the
Rust compiler, but maybe there is still a way I can help?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-lang/rust/issues/62918#issuecomment-531553785

@cavedweller I took a detailed look at your work-in-progress implementation at https://github.com/cavedweller/rust/commit/11c94220a62cd937090e9e6a04e50bb5f434ba6e today. I think the next step would be to adjust the MIR transformation in librustc_mir/transform/generator.rs, which transforms generators into "normal" state machines. I assume that we would need to adjust the code generated for yield and resume to take the new arguments into account. Unfortunately, I have no experience with MIR transformations, so I fear that this is over my head. I'll try to read up about MIR and see if I can understand this transformation, but I can't promise anything.

This is essentially a duplicate of https://github.com/rust-lang/rust/issues/56974, so closing in favor of that.

Was this page helpful?
0 / 5 - 0 ratings