this post was submitted on 13 Feb 2024
29 points (93.9% liked)

Rust

5346 readers
1 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 1 year ago
MODERATORS
top 7 comments
sorted by: hot top controversial new old
[–] [email protected] 9 points 7 months 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 7 months ago* (last edited 7 months 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 7 months ago (1 children)

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

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

You shouldn't, it's short and interesting

[–] [email protected] 1 points 7 months ago

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

[–] [email protected] 2 points 7 months 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 7 months 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.