D16298: prevent avahi signal racing

[Harald Sitter]

sitter created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
sitter requested review of this revision.

REVISION SUMMARY
  https://github.com/lathiat/avahi/issues/9
  
  Avahi has upstream signal races which can have any number of side effect
  bugs on our end ranging from unreliable discovery, over missing servers
  in kio slave listings, to outright deadlocking when waiting for a result
  which has already raced passed us (specifically RemoteService is vulnerable
  to that).
  
  When we make a request to avahi it will immediately start sending
  discovery signals even when we haven't even connected to the signals yet.
  This means any number of signals may be lost in the time between our
  request and us connecting to the signals.
  As this applies to (all?) in-the-wild versions of avahi even if we got an
  upstream fix today it'd not help the user until they get the new avahi
  integrated.
  
  To prevent us from losing the race all dbus signal listening is now done
  via blanket connects.
  Ordinarily we'd make a request, dbus would give us an object path, we'd
  connect to the object path's signals and then get signals for our request.
  Since the signals are racey we'll instead connect to all signals of a given
  interface (e.g. org.freedesktop.Avahi.DomainBrowser) completely ignoring
  the object path. We'll then "locally" filter all signals which belong to
  the specific DomainBrowser object as identified by the signals' dbus object
  path. This eliminates all risk of racing. Before we make the request
  we setup our blanket connections and the slots won't get called until after
  the event loop returns, which won't be until we've set "our" dbus object
  path for filtering later in the relevant functions.
  
  The obvious downsides of this are:
  
  - boilerplatey code for handling this stuff
  - runtime checked signal-slot compatibility
  - much more traffic going into our slots (doesn't actually end up doing any heavy lifting)

TEST PLAN
  - wrote a crappy test app to use all browser -> still browse (also service resolves)

REPOSITORY
  R272 KDNSSD

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D16298

AFFECTED FILES
  src/CMakeLists.txt
  src/avahi-domainbrowser.cpp
  src/avahi-domainbrowser_p.h
  src/avahi-publicservice.cpp
  src/avahi-publicservice_p.h
  src/avahi-remoteservice.cpp
  src/avahi-remoteservice_p.h
  src/avahi-servicebrowser.cpp
  src/avahi-servicebrowser_p.h
  src/avahi-servicetypebrowser.cpp
  src/avahi-servicetypebrowser_p.h
  src/avahi_listener.cpp
  src/avahi_listener_p.h

To: sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181018/435c6cb8/attachment.html>