I’m using sd-bus to develop the dbus part for fcitx5, because I’d like to seamlessly support kdbus in the future. (Don’t argue with me about bsd or sth else right now, for now I don’t care about that.)
But one api of sd-bus obviously blows up my mind.
https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/systemd/sd-bus.h#L428
typedef int (*sd_bus_track_handler_t) (sd_bus_track *track, void *userdata); int sd_bus_track_new(sd_bus *bus, sd_bus_track **track, sd_bus_track_handler_t handler, void *userdata);
So basically, it’s a wrapper around NameOwnerChanged dbus signal. And let you get notification about when the service disappears (only disappears, yeah).
And it also has capability to track more than one service name by using.
int sd_bus_track_add_sender(sd_bus_track *track, sd_bus_message *m); int sd_bus_track_remove_sender(sd_bus_track *track, sd_bus_message *m); int sd_bus_track_add_name(sd_bus_track *track, const char *name); int sd_bus_track_remove_name(sd_bus_track *track, const char *name);
And you are able to query which name is being tracked via:
unsigned sd_bus_track_count(sd_bus_track *track); const char* sd_bus_track_contains(sd_bus_track *track, const char *names); const char* sd_bus_track_first(sd_bus_track *track); const char* sd_bus_track_next(sd_bus_track *track);
So far so good, yeah?
But if you pay attention to the prototype of sd_bus_track_handler_t, you’ll notice that you won’t be able to get the tracked service name when this handler being called.
Which means you simply can’t use it to track more than one service name, because you can’t distinguish which service actually exits.
If I checked all existing usages of sd_bus_track in systemd, they imply that my impression is correct.
So obviously “tracking multiple name” functionality is totally useless.
So here, this is a good example about how this api should looks like: http://doc.qt.io/qt-5/qdbusservicewatcher.html .
For my own use case, I’ll go back to write my own service tracker with other sd-bus api.
