owned this note
owned this note
Published
Linked with GitHub
# Reading notes: How (and why) nextest uses tokio, part 1
Link to document: https://sunshowers.io/posts/nextest-and-tokio-1/
###### tags: `reading-club`
Leave questions, observations, discussion topics below.
---
## Topic
name: prompt
## Questions
- (vincenzopalazzo) The article is most about the difference between thread and async? looks like yes.
## Observations
>There’s a bit of a meme in the Rust world: that if you can “just use” threads, you should; and that async code is really only “worth it” for network services that need to be massively concurrent. (I don’t mean to pick on the individual authors here. It’s a general view in the Rust community.)
- (vincenzopalazzo) I disagree, message passing in thread is painful in my experience.
- (eholk) I think the author agrees with you, they are arguing async is useful even when you don't need to be massively concurrent.
- (vincenzopalazzo) Async IO make some scalable some test suite case, such as some test that deal with IO (save file, or monitor event with a log file)
---
(eholk) To me one of the key observations was that the async ecosystem gives you composable building blocks for dealing with asynchrony. Before the author had to use several bespoke event systems, like channels, signals, file descriptors, etc. After moving to async, these were all unified under a more generic async/await framework.
---
(eholk) It's interesting that the author makes such a big deal about `select!`. I wonder if other combinators would work just as well? Was cancellation an issue for the author?
(tmandry, in absentia) I didn't see an issue with cancellation but they do say:
> The main loop that selected across the test event and signal event channels hung during longer test runs; this was caused by a biased statement. Removing the biased fixed it, but I mostly found that out by trial and error. I’m not sure how to debug this kind of issue in a principled manner.
So I feel like this is a sign that select was still a source of bugs. I wonder if you could write this code using some of the primitives Yosh was exploring, like merged streams.
(eholk) Good point! I think it'd be interesting to try merged streams and such here.
---
>A panic with the message “async fn resumed after completion”. The solution to this was easy to find.
(vincenzopalazzo) This should never happens while use a runtime, right? maybe while you are developing a runtime yes, because it is a bug otherwise what it is a use cause that can cause this panic?
(tmandry) Select polls futures after completion, you have to `.fuse()` them if they don't support it.
(eholk) Ah, that makes sense that it comes from `select!`, I was thinking if you're using `.await` it should be pretty much impossible to poll a future after completion.
