<table><tr><td style="">sitter created this revision.<br />Herald added a project: Frameworks.<br />Herald added a subscriber: kde-frameworks-devel.<br />sitter requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D16298">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p><a href="https://github.com/lathiat/avahi/issues/9" class="remarkup-link" target="_blank" rel="noreferrer">https://github.com/lathiat/avahi/issues/9</a></p>

<p>Avahi has upstream signal races which can have any number of side effect<br />
bugs on our end ranging from unreliable discovery, over missing servers<br />
in kio slave listings, to outright deadlocking when waiting for a result<br />
which has already raced passed us (specifically RemoteService is vulnerable<br />
to that).</p>

<p>When we make a request to avahi it will immediately start sending<br />
discovery signals even when we haven't even connected to the signals yet.<br />
This means any number of signals may be lost in the time between our<br />
request and us connecting to the signals.<br />
As this applies to (all?) in-the-wild versions of avahi even if we got an<br />
upstream fix today it'd not help the user until they get the new avahi<br />
integrated.</p>

<p>To prevent us from losing the race all dbus signal listening is now done<br />
via blanket connects.<br />
Ordinarily we'd make a request, dbus would give us an object path, we'd<br />
connect to the object path's signals and then get signals for our request.<br />
Since the signals are racey we'll instead connect to all signals of a given<br />
interface (e.g. org.freedesktop.Avahi.DomainBrowser) completely ignoring<br />
the object path. We'll then "locally" filter all signals which belong to<br />
the specific DomainBrowser object as identified by the signals' dbus object<br />
path. This eliminates all risk of racing. Before we make the request<br />
we setup our blanket connections and the slots won't get called until after<br />
the event loop returns, which won't be until we've set "our" dbus object<br />
path for filtering later in the relevant functions.</p>

<p>The obvious downsides of this are:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">boilerplatey code for handling this stuff</li>
<li class="remarkup-list-item">runtime checked signal-slot compatibility</li>
<li class="remarkup-list-item">much more traffic going into our slots (doesn't actually end up doing any heavy lifting)</li>
</ul></div></div><br /><div><strong>TEST PLAN</strong><div><ul class="remarkup-list">
<li class="remarkup-list-item">wrote a crappy test app to use all browser -> still browse (also service resolves)</li>
</ul></div></div><br /><div><strong>REPOSITORY</strong><div><div>R272 KDNSSD</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D16298">https://phabricator.kde.org/D16298</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/CMakeLists.txt<br />
src/avahi-domainbrowser.cpp<br />
src/avahi-domainbrowser_p.h<br />
src/avahi-publicservice.cpp<br />
src/avahi-publicservice_p.h<br />
src/avahi-remoteservice.cpp<br />
src/avahi-remoteservice_p.h<br />
src/avahi-servicebrowser.cpp<br />
src/avahi-servicebrowser_p.h<br />
src/avahi-servicetypebrowser.cpp<br />
src/avahi-servicetypebrowser_p.h<br />
src/avahi_listener.cpp<br />
src/avahi_listener_p.h</div></div></div><br /><div><strong>To: </strong>sitter<br /><strong>Cc: </strong>kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>