GDBus usage in a library

Platform
1

Hi,

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?

Thanks

Anatol

1 Like
2

FYI if someone faces same issues. It turned out that the manual iteration of the main context from within the library should be fine. It appears to be both thread safe and non intrusive in regard to the consumer. No main loop is needed. The acquire function has to be used before the default main context can be iterated. This operation needs to be always done after any glib related operations, when events are assumed to be lost. For example after destroying a GDBusProxy object.

Still open to see if there are any better ideas.

Thanks

Anatol

3

I’m not sure I understand the premise. GDBus is using a worker thread running its own mainloop, and exposes an async api to users. Why do you think you need to iterate the default main context ?

4

Hi,

in this case the sync API has been used.

Thanks

Anatol

5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.