<table><tr><td style="">rjvbb added a comment.
</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/D8043" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>I did see some symptoms that could only be explained by a memory layout change (and apparently caused by this patch). Shame I didn't notice that before posting (I only tested with recompiled code).</p>

<p>Would it be possible to change the name of this virtualised class and use that to make a derived KDirWatch class that just reexports the methods as non-virtual (say with <tt style="background: #ebebeb; font-size: 13px;">using</tt>) - would that change the memory layout too (possibly in even more subtle ways)?</p>

<p>Anyway, pity. Making the class thread-safe internally will probably come with more overhead because it cannot use knowledge about how it's being used. It does look like KDW could do with an internal overhaul (but maybe what I perceive as an overly complex mess is a result of well-tested optimisation? ;)) Is there a reason a single QFSW instance is shared among all KDirWatch instances, for instance?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R244 KCoreAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8043" rel="noreferrer">https://phabricator.kde.org/D8043</a></div></div><br /><div><strong>To: </strong>rjvbb, Frameworks, mwolff, dfaure<br /><strong>Cc: </strong>dhaumann, cfeck, dfaure, mwolff, kde-frameworks-devel<br /></div>