mirror of
https://git.kernel.org/pub/scm/bluetooth/bluez.git
synced 2024-12-16 15:34:53 +08:00
6aa1c4488e
Consider the following example: /foo properties: "A", "B" /bar properties: "C", "D" If during a given mainloop iteration, property "A" of object '/foo' is changed, then properties "C" and "D" of '/bar', lastly "B" of '/foo', the current code will emit the PropertiesChanged signals in following order: "A", "B", "C", "D". This may confuse applications that have a dependency on the order of those signals. This fixes the ordering, so in the example, the order becomes: "C", "D", "A", B". This is considered not to be a problem, as applications may use the flag G_DBUS_PROPERTY_CHANGED_FLAG_FLUSH, so property changed signals are emitted as soon as possible. The solution is for each object, to reschedule the signals every time a signal is emitted. |
||
|---|---|---|
| .. | ||
| client.c | ||
| gdbus.h | ||
| mainloop.c | ||
| object.c | ||
| polkit.c | ||
| watch.c | ||