vim/YouCompleteMe
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Possible fix for random hang on Vim close

Browse Source 
Reparse would take the clang lock and then possibly call Destroy while still
holding the lock. Destroy would try to take that same lock, and the mutex is not
recursive. Unpleasantness ensues.

I _think_ this is the root cause of #218, but I can't be sure. Such is life with
threads.

Fixes #218.
This commit is contained in:
Strahinja Val Markovic 2013-04-10 19:45:50 -07:00
parent 89d93bc85c
commit 7ff4774e96
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
cpp/ycm/ClangCompleter/TranslationUnit.cpp
View File

@ -243,15 +243,18 @@ void TranslationUnit::Reparse(
// param though.
void TranslationUnit::Reparse( std::vector< CXUnsavedFile > &unsaved_files,
uint parse_options ) {
int failure = 0;
{
unique_lock< mutex > lock( clang_access_mutex_ );
if ( !clang_translation_unit_ )
return;
int failure = clang_reparseTranslationUnit( clang_translation_unit_,
failure = clang_reparseTranslationUnit( clang_translation_unit_,
unsaved_files.size(),
&unsaved_files[ 0 ],
parse_options );
}
if ( failure ) {
Destroy();
@ -262,9 +265,9 @@ void TranslationUnit::Reparse( std::vector< CXUnsavedFile > &unsaved_files,
}
// Should only be called while holding the clang_access_mutex_
void TranslationUnit::UpdateLatestDiagnostics() {
unique_lock< mutex > lock( diagnostics_mutex_ );
unique_lock< mutex > lock1( clang_access_mutex_ );
unique_lock< mutex > lock2( diagnostics_mutex_ );
latest_diagnostics_.clear();
uint num_diagnostics = clang_getNumDiagnostics( clang_translation_unit_ );