New user with a probably quick and/or frequent question but I seem to be having great difficulty finding documentation (or even this place to be frank; hope it’s the right one at least for this question).
I’m using GDBus from C to write a D-Bus service. Do I need to manually guard against a method_call into my service racing with get/set_property or even with itself? Or are things serialized at the D-Bus level already? If I’m myself responsible: is there utility infrastructure in place for this or do I just “manually mutex stuff”?
Seeing as how I’m rather taken aback at how hard it was to find an answer to this seemingly most basic of questions of anyone designing a first D-Bus service… so as to perhaps at least slightly assist a next poor web-searcher:
The D-Bus specification does not go near the subject which is supposedly to say it’s an at least potentially GDbus/QtDBus/libdbus/sd-bus/etc. specific question; as to GDBus it appears the case that any call into one’s method_call/get_property/set_property blocks any subsequent call into any of those three, and for the same or a different method/property.
I.e., no need to make things re-entrant with GDBus as far as I’ve been able to see. Same is likely true for all these frameworks in fact but I’ve looked in some detail only at GDBus’ behavior.
The documentation for g_dbus_connection_register_object() says:
Calls to functions in vtable (and user_data_free_func ) will happen in the thread-default main context of the thread you are calling this method from.
Which means that they will not be called in parallel. The execution of one of the vtable methods has to complete before another can be scheduled for that D-Bus object.
Thanks for the comment. Due to your formulation with the word “object” I thought I’d verify whether or not functions from different vtable’s, i.e., different interfaces on the same object path, are also mutually exclusive in that manner, and, yes, seems they are.
I’d however expected at that point that same or different interfaces on a different object path would then not be, but as far as I can see they are as well. I.e., a property_get() from any interface on object path /org/foo blocks a property_get() on object_path /org/foo/bar.
Would you say that’s correct and/or guaranteed? Did I mis/over-interpret your use of the word “object”?
It depends entirely on the context you’re calling g_dbus_connection_register_object() from for all of those D-Bus interfaces/objects.
If you’re making all the registrations from the same GMainContext (roughly, from the same thread), their vtable functions will not be called in parallel.
If you make some of the registrations from another GMainContext, the vtable functions from those other registrations may be called in parallel with the vtable functions from the first set (but not in parallel with themselves). And so on.