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.

Sign up for GitHub

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

Further improvements #34

Open
wants to merge 3 commits into
base: next
Choose a base branch
from
Open

Further improvements #34

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a36d0e2
further improvements
tronta Jan 5, 2023
cbaeb72
child components
tronta Jan 5, 2023
6d81857
update
tronta Jan 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/threads_and_async.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Let's say you have an application that fetches data from a website.
This leaves us in a similar situation as before: If we use a synchronous HTTP library in the update function, we will block our main thread and freeze the application until the server responds.
So instead, we're going to use Commands in this example.

Commands are background tasks that can be spawned using a `ComponentSender` or a `FactoryComponentSender`.
Commands are background tasks that can be spawned using a `ComponentSender` or a `FactorySender`.
They run until they return their result as a `CommandOutput` which in turn is processed again by the component.

First we define our message type, then we can use it as associated `CommandOutput` type in our component.
Expand Down Expand Up @@ -101,7 +101,7 @@ This can sometimes be problematic, for example when it comes to widgets.
Fortunately, the [`spawn_local`](https://relm4.org/docs/next/relm4/fn.spawn_local.html) function allows us to spawn local futures, which don't require `Send` because they run on the main thread.
This works because GTK uses an event loop from GLib to handle asynchronous events, which also allows you to execute futures.

The only drawback of this solution is that not all async libraries are fully compatible with the GLib executor, since they must use Tokyo.
A drawback of this solution is that you only can use libraries which support Tokio, as the GLib executor depends on it.
Copy link
Member

Choose a reason for hiding this comment

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

Actually, Glib doesn't depend on tokio, but many async crates do. For example, using reqwest in future on a GLib executor will panic because it needs some tokio-specific features. This is not obvious for beginners because it should be as simple as using async/await but sadly that's not true in reality.


# Summary

Expand Down