Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> 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.
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].
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...