-
> The big HTTP libraries let you opt out (of async)
At least for reqwest it just wraps the async code in something like `block_on`: https://github.com/seanmonstar/reqwest/blob/5397d2cf8eaecc9f...
And as the sibling comment says, you can do that in your own code. It does still add Tokio to your binary size, and probably start a bunch of worker threads you don't need, but it does work.
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
This is a consequence of runtimes relying on global variables that their core future types are dependent on. Creating abstractions to solve this problem is one of the main goals of the the async working group [0].
[0]: https://github.com/rust-lang/wg-async
-
-
There's waiters and polling that only executed your function to progress and there's pending and done. Any help to understand the relationship between the three things would be appreciated.
I wrote a M:N thread scheduler in C, Java and Rust. The C version also can schedule file reading to an IO thread but I'm nowhere near finished.
https://github.com/samsquire/preemptible-thread
Another of my ideas is to rewrite synchronous code into parallel LMAX disruptors. In other words a tree of RingBuffer each line of synchronius code its own event loop. Rather than one event loop multiplexing events from different systems you pipeline every blocking call. I think it would be very fast.
Here's a write-up.
https://github.com/samsquire/ideas4#51-rewrite-synchronous-c...
-
There's waiters and polling that only executed your function to progress and there's pending and done. Any help to understand the relationship between the three things would be appreciated.
I wrote a M:N thread scheduler in C, Java and Rust. The C version also can schedule file reading to an IO thread but I'm nowhere near finished.
https://github.com/samsquire/preemptible-thread
Another of my ideas is to rewrite synchronous code into parallel LMAX disruptors. In other words a tree of RingBuffer each line of synchronius code its own event loop. Rather than one event loop multiplexing events from different systems you pipeline every blocking call. I think it would be very fast.
Here's a write-up.
https://github.com/samsquire/ideas4#51-rewrite-synchronous-c...
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.