[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals

[Dan Williams]

On Sat, 2011-10-22 at 13:54 -0700, Grant Erickson wrote:
> 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:
> >> 
> >>        http://lists.shmoo.com/pipermail/hostap/2011-October/024363.html
> >> 
> >> 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
> of remediation.
> 
> That said, the deficiency lies in the supplicant not network managers such
> as connman and flimflam and the supplicant is where this deficiency should
> be corrected.

I used to have a problem with this, but I now see where it makes sense
for the State property alone.  Most properties *should* be coalesced to
reduce dbus traffic, but the State property should probably just trigger
an immediate emit of the interface's changed properties.  State doesn't
change that often so it wouldn't meaningfully increase D-Bus traffic.

Dan