Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

book: Move to async-channel #1521

Merged
merged 1 commit into from
Oct 22, 2023
Merged

Conversation

Hofer-Julian
Copy link
Collaborator

async-channel covers more use cases.
This also fits with my observation that it is popular within gtk-rs apps

async-channel covers more use cases.
This also fits with my observation that it is popular within gtk-rs apps
@Hofer-Julian Hofer-Julian merged commit 3641400 into master Oct 22, 2023
3 checks passed
@Hofer-Julian Hofer-Julian deleted the Hofer-Julian/async-channel branch October 22, 2023 10:55
@sdroege
Copy link
Member

sdroege commented Oct 22, 2023

It might be worth mentioning in the book why you use async-channel (I'm usually also using that, or just the channels from the futures crate...).

Should we maybe remove the GLib channel? It mostly exists from the times before async was mature and because people instead used timeout callbacks to periodically check if a non-async channel contains something.

@Hofer-Julian
Copy link
Collaborator Author

It might be worth mentioning in the book why you use async-channel

Over the futures one? Tbh, I didn't know that one existed.
Could you tell me what's the reason to choose one over the other?

Should we maybe remove the GLib channel? It mostly exists from the times before async was mature and because people instead used timeout callbacks to periodically check if a non-async channel contains something.

I think that would be good, yes.
Should I open an issue for that?

@sdroege
Copy link
Member

sdroege commented Oct 27, 2023

Could you tell me what's the reason to choose one over the other?

async-channel is a more modern implementation. I think it's more lightweight, has lower overhead and IIRC there's also some minimal API differences?

Probably doesn't matter too much of the majority of applications which one you use.

Should I open an issue for that?

Yes please

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.

None yet

2 participants