when writing a library consuming a DBUS service, what is the guidance regarding of the main loop usage? Questions in particular, what are the best practices when writing a library consuming DBUS over GDBus, if that library
- Might be consumed by an application not iterating a main loop
- Might be consumed by an application iterating a main loop, and that main loop won’t be owned by the library
- Might be used in a thread
- An API might require a GDBusProxy to persist between requests
- The GDBusProxy object might be passed between threads
Reading the GDBus documentation and observing the related tests in gio/tests, it seems that the main use case with GDBus is an application that owns the default main context and the default main loop. I might oversee something, though. If so, please could someone point to the applicable docs?
In general, as glib guidance tells - "Libraries should never use g_main_context_default() ", is this appclicable in a case like this? Say in worst case, the library would be linked with an application not consuming any of glib APIs, and thus no context iteration might take place. Is it fair to say, that in that case the library still should start the default main loop?
The GDBusProxy specific point is also, " A GDBusProxy instance can be used from multiple threads but note that all signals (e.g. “g-signal”, “g-properties-changed” and “notify”) are emitted in the thread-default main context of the thread where the instance was constructed." Does this imply, that even if a GDBusProxy object is using its own thread-specific context, it would still require a the global main loop to be iterated?
To summarize the above - what are the best practices on using GDBus from a DSO under the condition, that the consuming party might be not iterating the default main context?