this post was submitted on 13 Feb 2024
28 points (93.8% liked)

Rust

6669 readers
42 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
top 7 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 1 year ago

Great post!

I ran into this problem when working with gtk-rs. For every async library that you use, you have to look carefully if it requires a specific runtime. If you want to eg. make a HTTP request with reqwest you need to make sure to spawn a task on a tokio runtime running in the background.

[–] [email protected] 6 points 1 year ago* (last edited 1 year ago)

Here's my main takeaway with simpler language:

Rust doesn't provide a way to abstract over async runtimes, so futures need to embed that somehow if they need access to it. So if you try to use functions intended for another runtime, you can get crashes.

This seems like it could be solved by providing an async runtime implementation in std that could be swapped out if desired (like the memory allocator).

[–] [email protected] 3 points 1 year ago (1 children)

Well, this one goes to my “save but never read” box.

[–] [email protected] 8 points 1 year ago (1 children)

You shouldn't, it's short and interesting

[–] [email protected] 1 points 1 year ago

Yep it was good. I also read original JS version article too 😄

[–] [email protected] 2 points 1 year ago

Interesting idea indeed. I've never used async yet, but I'm always surprised at how the problem space seems to be much more complicated than what it initially looks like.

[–] [email protected] 1 points 1 year ago

The example FileDescriptorPollContext doesn't really work. What if my runtime uses io-uring instead of polling? Those need very different interfaces to be sound. How do you abstract over that.