Review Request 128829: [1/2] clang parse job: do initialization in run(), not in the constructor

[Milian Wolff]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128829/#review98896
-----------------------------------------------------------



-1

I agree that there is an issue we need to fix, see: https://bugs.kde.org/show_bug.cgi?id=355100

but I disagree with the way you tackle the issue. Imo, we should try to find a way to create the parse job without holding the background parser mutex somehow. I.e. instead of fixing N parse job implementations, only fix the background parser - somehow. I'd like to investigate this tomorrow or so. Do you have any time the following days to discuss this? Or do you think it's impossible?

- Milian Wolff


On Sept. 4, 2016, 3:37 p.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128829/
> -----------------------------------------------------------
> 
> (Updated Sept. 4, 2016, 3:37 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> The constructor of the parse job is called from createParseJob(), which
> is called from the background parser with the background parser mutex
> locked. If the constructor acquires a DUChain lock (which it did), then
> any thread which acquires the DUChain lock first and then the background
> parser mutex will cause a deadlock. Other language plugins do this a lot,
> esp. qmljs and to some extent also python, by calling
> BackgroundParser::isQueued() with the DUChain lock held.
> 
> By doing the initialization in run() with the ForegroundLock held,
> we avoid this problem.
> 
> This is a severe bug, I hit it quite often and I have read more than one
> report from users complaining about freezing as well.
> 
> Requires https://git.reviewboard.kde.org/r/128830/ or it will just assert out.
> 
> 
> Diffs
> -----
> 
>   languages/clang/clangparsejob.h 7c0ab7a 
>   languages/clang/clangparsejob.cpp d676aea 
>   languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 590ba4a 
>   languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp df1be68 
> 
> Diff: https://git.reviewboard.kde.org/r/128829/diff/
> 
> 
> Testing
> -------
> 
> Opened several large sessions in a debug build, didn't see any more freezes during initial parsing. Before this was really easy to observe if you opened a C++ and a JS project in parallel.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160905/574a318d/attachment.html>