<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 9:42 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey all, esp. Aleix.<br>
<br>
While working on the project filter I encounter an issue when trying to<br>
integrate it into the CMake ProjectManager: Since the CMake manager uses a<br>
threaded import, I would need to make the project filters threadsafe which imo<br>
should not be done.<br>
<br>
Generally, considering the history of bugs and crashes as well as looking at<br>
the hacks and workarounds we have added, I think it's time to revisit the<br>
decision to "parallelize" the cmake import.<br>
<br>
I'm all for optimizations, as you all hopefully know, but this is simply bad.<br>
Esp. considering that for every crash that was encountered, another mutex was<br>
added (similar to the DUChain code) this does not even scale half as good as<br>
it should.<br>
<br>
So, I propose the following:<br>
<br>
# kill the threading<br>
<br>
- remove the QtConcurrent stuff from the ImportProjectJob<br>
- kill all mutices and locking in the CMakeProjectManager (except for DUChain<br>
stuff)<br>
- remove the project model threading hack<br>
<br>
# refactor the code<br>
<br>
- only support async "import" operations in ProjectFileManager, i.e. only<br>
"createImportJob" and get rid of "import" and "parse"<br>
- make the ImportProjectJob a KCompositeJob such that its possible to add<br>
child jobs to it<br>
- add new child jobs for every CMakeLists.txt (share code if possible, we need<br>
the same for Makefiles and QMake files in their respective managers)<br>
NOTE: these jobs then internally should parse the files in a separate thread<br>
- this should also make it trivial to use the AbstractFileManager code for the<br>
CMakeManager and only add the custom CMakeLists.txt parsing + target creation<br>
+ refactoring on top of that<br></blockquote><div><br></div><div style>I'm wondering if the work could be split up into more/separate milestones, i.e. as a first step just make the import-job not use threading anymore (and block the UI during the import again). Then refactor it so it runs multiple child-jobs until everything is done in batches so the UI gets responsive again. Then you can drop all the mutexes from the cmake manager. At that point you'd be thread-free, but probably quite a bit slower again (and blocking the UI more), however the individual steps could be easier/faster to accomplish and you don't live in a broken branch for such a long time.</div>
<div style><br></div><div style>Once you have the import job as composite and sub-jobs you could start moving the sub-jobs to the manager so it can do its own threading if it wants to.</div><div style><br></div><div style>
Andreas</div></div></div></div>