I'm using the #reqwest crate to call two different APIs. One is working fine, the other I had working intermittently but not sure what fixed/unfixed it.
The issue is that the await doesn't return even though using curl works fine.
Why would await not return after a few seconds when the curl request returns immediately?
This issue appears not to be a problem with the API or my code using #reqwest to access it.
The request stays pending indefinitely. I'm not sure why yet, that code is full of futures dragons, but it suggests that there may be a problem caused by how I'm using futures, maybe causing a deadlock under the hood.
Just guessing, but going to call the web API from the outer loop alongside the other futures threads rather than inside its own future, maybe use blocking #async#Rust
A timely blog from Tyler Mandry supports the possibility that my issue could arise from the way I'm using futures.
He mentions some facerakes which can occur using select! rather than merge! to combine futures so that's another avenue to pursue. Bonus: I will learn to produce more reliable async code.
Very interesting and commendable blog post on the state and future [cough] of #async#Rust:
As suspected the issue was not in the code I created to use remote web APIs.
The issue was that using the async function which polls the web APIs as a tokio::future was preventing the await on the web request from ever returning, even though the remote web API was responding correctly.
I fixed this by doing the polling of the my async function manually alongside the select! macro which handles the other two futures, all within a loop.
"io_uring is a new asynchronous I/O API for Linux created by Jens Axboe [...]. It aims at providing an API without the limitations of the current select(2), poll(2), epoll(7) or aio(7) family of system calls [...]."
> "Let’s be honest, #Async Rust is hard. It has many more rough edges than Sync Rust and requires a different mindset, but it solves a problem space well, that is hard to tackle otherwise. It allows safer network concurrency than C++ Boost.Asio and I would start this post by giving a big thanks to the Tokio team & ecosystem for the amazing work they provide to the community."
Using #RevoltPHP for one of my new projects. It's very nice working with #PhpFibers and not dealing with generators/promises as much. Can't wait for other #Async#Frameworks to start refactoring to use it more. I know #AmpPhp has added it to their HttpServer lib already.
One of the big pain points for me with #async#rust is the gap between async features and the rest of the languages. For instance, you need external crates for async traits and closures and the errors become unreadable once they involve those async traits.
@notgull This is such a good blog post. I've learned a lot!
Thank you for sharing. ❤️
"The best part is that the allocation, the Vec<smol::Task<()>>, isn’t even necessary. It could be one-time allocation that is just extended to hold the tasks."
Wow, this is mind-blowing to me - I haven't even considered this before! 🤯