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

Research migrating to new async runtime (async-std -> tokio) #87

Closed
a-moreira opened this issue Oct 23, 2023 · 10 comments
Closed

Research migrating to new async runtime (async-std -> tokio) #87

a-moreira opened this issue Oct 23, 2023 · 10 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@a-moreira
Copy link
Collaborator

a-moreira commented Oct 23, 2023

async-std is not well maintained anymore, and tokio seems to be the de-facto choice for an async runtime in Rust:
https://corrode.dev/blog/async/

@a-moreira a-moreira converted this from a draft issue Oct 23, 2023
@a-moreira a-moreira added the enhancement New feature or request label Oct 23, 2023
@a-moreira a-moreira self-assigned this Oct 24, 2023
@Davidson-Souza Davidson-Souza added this to the v0.6.0 milestone Nov 21, 2023
@lordshashank
Copy link
Contributor

@a-moreira @Davidson-Souza , I was looking into the migration, few queries on this-

  • async-std's unbounded function gives sender and reciever, while using tokio we would have choice of UnboundedSender and Sender, would it be better to use unbounded_channel or channel (unbounded one imo)?
  • tokio::net::TcpStream does not implement clone, i guess we would have to use Arc<Mutex<TcpStream>> to share stream between multiple tasks which would need whole code revamp, is there any better way?

@a-moreira
Copy link
Collaborator Author

@lordshashank

  • Use Tokio's Unbounded Channels.
  • this is a good question, IMHO I'd be better to avoid putting TcpStream into an Arc, and instead move it to a separate thread where we communicate via channels (actor model), but that might require a big re-write.

@a-moreira
Copy link
Collaborator Author

a-moreira commented Apr 8, 2024

@lordshashank I started this effort here https://github.com/Davidson-Souza/Floresta/pull/110 but had to back away due to some personal reasons. Maybe that helps.

@jaoleal
Copy link
Contributor

jaoleal commented Apr 11, 2024

This issue was proposed as a Summer of Bitcoin assignment right ? Can someone add the summer-of-bitcoin label ?

@a-moreira
Copy link
Collaborator Author

@jaoleal I'm not aware of that, are you @Davidson-Souza?

@jaoleal
Copy link
Contributor

jaoleal commented Apr 11, 2024

@jaoleal
Copy link
Contributor

jaoleal commented Apr 11, 2024

I can create the issue and tag both of you @a-moreira and @Davidson-Souza if you all prefer this way, since the tittle for this one is about research only... If so, I do appreciate some time so i can get more information about the work to be done, the affected modules, final objective, info source and etc...

@a-moreira
Copy link
Collaborator Author

@jaoleal cool! It's ok for me.
Regarding the research part, I think it's pretty much decided that we should move away from async-std and use Tokio. It's just a matter of starting the refactor, which will not be small.

@Davidson-Souza
Copy link
Collaborator

Hi @jaoleal. Yes, this project is one of my SoB's project ideas. I agree with @a-moreira, we know we want to do this, we just need to actually do.

@Davidson-Souza Davidson-Souza moved this from Todo to In Progress in Floresta Project May 28, 2024
@Davidson-Souza
Copy link
Collaborator

Done in #172

@github-project-automation github-project-automation bot moved this from In Progress to Done in Floresta Project Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants