https://bugs.kde.org/show_bug.cgi?id=372040
--- Comment #16 from RJVB <rjvber...@gmail.com> --- (In reply to Milian Wolff from comment #14) > this should be fixed by making sure the unknown declaration problem its > check in another thread How about using handling the headerdir scan in a QProcess, and using a local QEventLoop to handle event processing while waiting for the scan job to finish? Not as elegant as other solutions, but it would probably be an easy way to test the benefits of a multithreaded approach? It seems that if we subclass QEventLoop we could override QEventLoop::event() to catch events that justify bailing out of the current scan operation. Because however I look at it, scanning all include directories for a possible solution to a missing declaration remains expensive, esp if - it's done every time the missing declaration gets focus - it always runs to completion even if the user shifted the focus elsewhere and the solution is thus no longer needed. I'll see how trivial (or not) it is to implement these ideas. Do we agree that only a single unknown declaration problem should be processing at any given time, i.e. that any ongoing scan should be aborted when another request comes in? I also think that it would be very useful if each problem of this kind scanned a given set of headerfiles only once. That doesn't seem trivial to implement; a reset would be required when the headerdir search path changes but also when additional files are installed or files are edited. Clang supports precompiled headers. Wouldn't it be possible to let the parser and ClangProblem features use a precompiled header of all headers in the search path? Keeping the .pch file is something that would be perfectly suitable for a background thread. -- You are receiving this mail because: You are watching all bug changes.
