Add spawn_future and spawn_future_local convenience functions

[Hofer-Julian]

A couple of gtk-rs apps currently use utility functions to make spawning futures less verbose.
See:

• https://docs.rs/gtk-macros/0.3.0/gtk_macros/macro.spawn.html
• https://gitlab.gnome.org/GNOME/loupe/-/blob/main/src/util/mod.rs#L251

Exposing these functions via glib should fulfill that need.

[sdroege]

@bilelmoussaoui What do you think?

[pbor]

Shall these use glib::MainContext::ref_thread_default().spawn_local etc?

[sdroege]

Shall these use glib::MainContext::ref_thread_default().spawn_local etc?

The goal here seems to be to actually get the global default main context. But you're right, from the function names I would also expect it to work on the thread default one.

[Hofer-Julian]

The goal here seems to be to actually get the global default main context. But you're right, from the function names I would also expect it to work on the thread default one.

I have to admit that I don't know what the difference would be in practice.

[sdroege]

None at all unless you create other main contexts in your application and run those from other threads. That seems very uncommon in GTK applications, but for example is how the GDBus thread and some other helper threads inside GIO work. It's more common a pattern in libraries.

[Hofer-Julian]

None at all unless you create other main contexts in your application and run those from other threads. That seems very uncommon in GTK applications, but for example is how the GDBus thread and some other helper threads inside GIO work. It's more common a pattern in libraries.

I guess, in that case, I wouldn't mind changing it to glib::MainContext::ref_thread_default().spawn* if that makes stuff clearer and/or makes the function applicable for more use cases.

[sdroege]

It would only behave differently if you run it from a thread that explictly set another main context as the thread default one. It would behave exactly the same as GIO async operations (and GTask) in that regard.

[Hofer-Julian]

It would only behave differently if you run it from a thread that explictly set another main context as the thread default one. It would behave exactly the same as GIO async operations (and GTask) in that regard.

I understand :)
Which option is more sensible in your opinion?

[sdroege]

The behaviour of GTask, using the thread default one. The main reason why some APIs (g_idle_add() etc) don't do that is for backwards compatibility reason.

[Hofer-Julian]

The behaviour of GTask, using the thread default one

Okay! I've adapted the PR accordingly.