Hello Guys, On Wed, Apr 24, 2013 at 4:01 PM, Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx> wrote: > On Wed, Apr 24, 2013 at 3:36 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: >> Hi Lucas, >> >> On Wed, Apr 24, 2013, Lucas De Marchi wrote: >>> > 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. >>> >>> ugh.. no. This doesn't play well with sending the message directly >>> through libdbus. >> >> Is that something we really want to explicitly support instead of >> encouraging code to always use gdbus functions? > > Unless we create a complete wrapper over libdbus functions that we > need, there's no encouraging thing here. It's just needed in some > places. > > >> >>> When we implemented the properties interface, the manner we talked >>> about doing this (if it was indeed needed) was mostly what Luiz is >>> saying now. I think I even sent a patch to this mailing list >>> containing this flag. You would add something like: >>> >>> G_DBUS_PROPERTY_FLAG_IMMEDIATE (or some better naming). Then >>> g_dbus_emit_property_changed() would check this flag, in which case >>> process_changes() would be called synchronously. I don't see why this >>> wouldn't solve your problem and it doesn't require an API change. For >>> the exceptional cases in which this is needed, we add such flag. And >>> if a property needs to be sent immediately in one place I think it >>> always will. Or am I missing something? >> >> The main point I was trying to present is that it would be nice if when >> you have code like: >> >> foo(); >> bar(); >> baz(); >> >> and each of those calls create a D-Bus message (property signal method >> call/return, etc) that needs to be sent, that you could count on the >> messages being sent in the same order that they happen in the code. This >> kind of intuitiveness would be nice to have regardless of whether we're >> dealing with a special case that really needs it or not. > > Any of the proposed solutions do this. Your solution involves not > marking the special cases, but on the other hand makes the special > cases the default and needs some more working on gdbus to cover all > the uses of dbus_connection_send_* > > I'm not saying it's not a good solution, bit I'm not sure it's the > best one neither. > > Can we get back to this topic? This problem is still present in the master branch and affecting our support for HFP in oFono. -- João Paulo Rechi Vita http://about.me/jprvita -- 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
