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

Please update futures-rs to 0.3.1 #298

Closed
Silentdoer opened this issue Nov 25, 2019 · 24 comments
Closed

Please update futures-rs to 0.3.1 #298

Silentdoer opened this issue Nov 25, 2019 · 24 comments

Comments

@Silentdoer
Copy link

@Silentdoer Silentdoer commented Nov 25, 2019

Hi, please update futures to 0.3.1

@Silentdoer Silentdoer changed the title async await Please update futures-rs to 0.3.1 Nov 25, 2019
@Luminoth

This comment has been minimized.

Copy link

@Luminoth Luminoth commented Nov 26, 2019

It would be great if an update to tokio 0.2 could come along with this

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 26, 2019

tokio team did nice thing, actix now is not compatible with tokio anymore

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 26, 2019

@fafhrd91 what?! How so?!

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 26, 2019

This framework is one of the biggest built on top of tokio so I think we'd have some weight for asking for backwards compatibility of a certain form.

What changed in last few days?

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 26, 2019

You can not spawn !Send futures anymore. I am planing to add custom runtime and drop tokio dependency

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 26, 2019

So something specific in the executor? Any idea why this new design decision?

Wouldn't building a runtime for actix be quite a huge feat? Why not just fork and add feature to tokio worst case?

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 26, 2019

Actix is single threaded, tokio mostly multithreaded. Actix does not need any complexity

@asonix

This comment has been minimized.

Copy link

@asonix asonix commented Nov 26, 2019

There exists work to provide support for !Send futures in tokio: tokio-rs/tokio#1733

Rather than introduce an additional asynchronous runtime (we already have tokio and async-std) it might be worth waiting for tokio to again support !Send

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 26, 2019

actix uses maybe 10-15% of tokio, I am not sure why I need other 85% all the time.

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 26, 2019

But obviously, modularity is not a concern anymore.

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 26, 2019

Async-std works currently? That's news to me. Where can I find the different runtime "modules" source code? And any instructions for implementing a new one?

Which actix repos/folders to dig into?

@asonix

This comment has been minimized.

Copy link

@asonix asonix commented Nov 26, 2019

@cdbattags I wasn't trying to imply that actix works on top of async-std or tokio 0.2, I was just stating that these options exist as asynchronous runtimes, and I didn't think introducing a third asynchronous runtime was a good idea.

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 26, 2019

Ahhh @asonix you were just referring to there existing multiple runtimes for futures in the Rust eco right now?

@fafhrd91 the way I look at it is that the 85% we don't use slows crate/package download time and compile time but that's about it, no?

If we need to reduce binary size later we can approach a new runtime then, no?

And why is modularity "not a concern anymore"?

@hawkw

This comment has been minimized.

Copy link

@hawkw hawkw commented Nov 26, 2019

FWIW, in the new tokio 0.2 release, it should be much easier for crates like Actix to opt in only to the features they use, via feature flags: tokio-rs/tokio#1811

This was intended primarily for libraries which need only some features from tokio but don't want to burden their users with longer compile times. :)

And, spawning !Send futures will probably have made it back in by tokio 0.2.1 — we know that's currently a blocker for some use cases!

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Nov 27, 2019

At the moment we are evaluating option to drop tokio completely

@krircc

This comment has been minimized.

Copy link

@krircc krircc commented Nov 27, 2019

@cdbattags Current async-std also can not spawn !Send futures

@hawkw

This comment has been minimized.

Copy link

@hawkw hawkw commented Nov 27, 2019

The current master version of tokio now has an API for spawning !Send futures, and it should be released in the near future. Hopefully this helps!

@Extrawurst

This comment has been minimized.

Copy link

@Extrawurst Extrawurst commented Nov 27, 2019

@cdbattags

This comment has been minimized.

Copy link
Member

@cdbattags cdbattags commented Nov 28, 2019

@kanekv

This comment has been minimized.

Copy link

@kanekv kanekv commented Dec 1, 2019

Btw, if actix moves away from tokio it will be painful to use other crates that require tokio runtime (tonic, hyper, etc)?

@gzp-crey gzp-crey mentioned this issue Dec 3, 2019
0 of 1 task complete
@carllerche

This comment has been minimized.

Copy link

@carllerche carllerche commented Dec 3, 2019

@fafhrd91 It's unfortunate to hear, I would be eager to talk out the points in 0.2 that don't work for you. I had reached out to you in the past to ask for early feedback to make sure the changes worked for Actix, but unfortunately you did not have any availability. We did our best to ensure that the Actix case was covered.

But obviously, modularity is not a concern anymore.

Modularity is a big concern. Using feature flags, we can reduce the total amount of code while providing greater flexibility (mixing feature flags cross crates did not work very well). You can still only enable the components that you need. If there is something more specific, I would love to hear it.

You can not spawn !Send futures anymore.

As mentioned by others, this is now supported. The very initial release of 0.2 shipped without task::LocalSet, but mostly to get something out the door as task::LocalSet is forwards compatible. I would say that being able to fully decouple the concern of scheduling !Send tasks from the concern of I/O shows greater modularity?

Anyway, if you have specific issues you wish to discuss, please ping me or open an issue on the Tokio repo and I would be happy to work through them.

@fafhrd91

This comment has been minimized.

Copy link
Member

@fafhrd91 fafhrd91 commented Dec 4, 2019

My initial thoughts was related to 0.2.0 release. I think LocalSet should work.

Closing ticket as path for actix actors to async/await is not clear yet

@fafhrd91 fafhrd91 closed this Dec 4, 2019
@gzp-crey

This comment has been minimized.

Copy link

@gzp-crey gzp-crey commented Dec 4, 2019

And what about projects those are targeting actix-web 2.0 and require the Actor model ? Is there another tracking issue for this? For now the actix-web 2.0 without actor model is a huge braking change that'll hurt many projects.
If there is an alternative solution than please provide a migration guide.

@glademiller

This comment has been minimized.

Copy link
Contributor

@glademiller glademiller commented Dec 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.