Skip to content

Conversation

@thomaseizinger
Copy link
Contributor

No description provided.

But it's another weapon in your arsenal which should be considered. So next time you are reaching for `Arc<Mutex<T>>` in async code, consider if it could instead be written in `Poll`-style.
But it's another tool in your arsenal which should be considered. So next time you are reaching for `Arc<Mutex<T>>` in async code, consider if it could instead be written in `Poll`-style.

<!-- I was never a fan of the term "poll-style". All futures are poll-style, the difference is whether you write them yourself or the compiler does it for you. I think "hand-rolled" futures might be a better term?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes hand-rolled is a much better term.


<!-- I was never a fan of the term "poll-style". All futures are poll-style, the difference is whether you write them yourself or the compiler does it for you. I think "hand-rolled" futures might be a better term?
In general, I think you might want to come up with a more complex example. Many problems can be solved with Rust's built-in `async` lowering. Even if you have shared state between them, they can often be modelled as multiple streams of events that all get "merged". In your case, you could merge both intervals into a single stream, poll / await that and then update the state on each event. That way, you'd also have a single owner of the state again and Rust will happy compile it.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah you're right, it feels too artificial here that both "events" update the state when it could be trivially extracted from within the futures. I need to spend some time coming up with a better example.

Thanks for this feedback! It's super useful

@conectado
Copy link
Owner

Thanks again a lot for the feedback, it's been beyond invaluable! <3 I've been thinking through it a lot these weeks and I've come up with #31 (WIP right now) in place of this article.

@conectado conectado closed this Jul 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants