Hi Johan, On 16:58 Wed 24 Apr, Johan Hedberg wrote: > Hi, > > On Fri, Apr 19, 2013, Vinicius Costa Gomes wrote: > > On 09:30 Fri 19 Apr, Luiz Augusto von Dentz wrote: > > > What about creating a new flag for properties that need to emit a > > > signal immediately when they change? > > > > That would also solve the problem. > > > > The way I see it, we should still not make any guarantees about when > > a propery changed signal will be emitted, only when the API behaviour > > requires, we use some kind of barrier to keep the ordering in check. > > > > And having a function to call we make it easier to detect when this > > is abused, i.e. we know there's something very wrong if there's a flush > > after each emit. > > Is this where the discussion got stuck? Since this feature is really > only needed for quite exceptional situations if an API change needs to > be done I'd be in favor of a separate flush function. > > Another option is to make *all* D-Bus messages that gdbus sends to use > an idle callback, including method calls and returns. In the idle > callback the messages would be sent in the same order as they were added > to the send queue. This would not require any changes to the gdbus API. In this situation we are not using g_dbus_send_message(), we are using dbus_connection_send_message_with_reply(). > > Johan Cheers, -- Vinicius -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
