[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals
marathon96 at gmail.com
Sat Oct 22 16:54:42 EDT 2011
On 10/22/11 1:25 PM, Sam Leffler wrote:
> On Fri, Oct 21, 2011 at 5:22 PM, Grant Erickson <marathon96 at gmail.com> wrote:
>> Per thread:
>> the supplicant property coalescing and queueing logic break network
>> managers such as connman or flimflam in subtle and often random ways.
>> This set of patches provides a priority, fast-track path for the State
>> property that avoids queuing and dispatching it as with other
>> properites to ensure that higher-level network managers see all
>> supplicant state changes.
> NAK. flimflam is not affected by the coalescing state change signals
> and the coalescing effectively reduces traffic over the dbus.
In the common case for BSSs, etc. I can see where coalescing seems like a
reasonable approach and the submitted patch leaves all of those properties
as-is--they remained coalesced.
For state changes (i.e. the "State" property), I cannot see where coalescing
makes any measure of sense. State changes don't strike me as frequent enough
or high bandwidth enough where losing the information contained therein is a
trade-off worth making.
> If you want to add something to inhibit coalescing please have the client
> explicitly enable it. Otherwise you may care to look at how flimflam
> handles things.
I've looked at it and I felt that it is sufficiently divergent from
connman-0.77 where an adoption of that approach didn't make sense as a point
That said, the deficiency lies in the supplicant not network managers such
as connman and flimflam and the supplicant is where this deficiency should
More information about the HostAP