Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Several improvements to Code Completion plugin
ollydbg:
--- Quote from: ollydbg on February 16, 2014, 03:00:30 pm ---
--- Quote from: Huki on February 15, 2014, 03:50:49 am ---...
...
It's actually working very well - I have no more hangs now during batch parsing. I don't have a problem with the use of sleep function, it achieves the purpose, i.e., release the mutex before each include file, (very similar to the old behavior before the includes patch when the files were simply added to the end of the queue).
--- End quote ---
Thanks, yes, it works well (on my winXP system), so if no objections, I will commit this change.
--- End quote ---
BTW: any one can test the patch(in this reply) on Linux? Thanks.
Huki:
--- Quote from: ollydbg on February 16, 2014, 03:00:30 pm ---
--- Quote from: Huki on February 15, 2014, 03:50:49 am ---...
...
It's actually working very well - I have no more hangs now during batch parsing. I don't have a problem with the use of sleep function, it achieves the purpose, i.e., release the mutex before each include file, (very similar to the old behavior before the includes patch when the files were simply added to the end of the queue).
--- End quote ---
Thanks, yes, it works well (on my winXP system), so if no objections, I will commit this change.
--- End quote ---
I'm ok with committing this patch, can confirm it works fine on Win 7 / 8.
--- Quote from: ollydbg on February 16, 2014, 03:00:30 pm ---
--- Quote ---The proper solution would probably be to ensure that the tokentree mutex is not accessed by the GUI while parsing, but this is not very easy.. lot of things the user does - mouse hover over a symbol, clicking into a function block, etc., will trigger the GUI to try access the mutex.. those are the times when I noticed the hangs actually.
--- End quote ---
The old behavior, when the parser is working, then gui access to tokentree was forbidden until parser finishes batch parsing, user will see some tips like "Parser is running, so no tip available". And later Loaden (one of C::B dev, but he was not active for years now) added many lockers to let the tree access from multiply thread.
So, do you think we need to change back to the old behavior? I hate those lockers. :)
--- End quote ---
We can try changing back to the old behavior, I don't see any reason to access the tokentree before parsing is finished (we don't display tooltips anyway). Is it this kind of check that we find in NativeParser::MarkItemsByAI()?
--- Code: --- if (!m_Parser->Done())
{
wxString msg(_("The Parser is still parsing files."));
msg += m_Parser->NotDoneReason();
CCLogger::Get()->DebugLog(msg);
return 0;
}
--- End code ---
ollydbg:
--- Quote from: Huki on February 25, 2014, 07:44:50 am ---
--- Quote from: ollydbg on February 16, 2014, 03:00:30 pm ---
--- Quote from: Huki on February 15, 2014, 03:50:49 am ---...
...
It's actually working very well - I have no more hangs now during batch parsing. I don't have a problem with the use of sleep function, it achieves the purpose, i.e., release the mutex before each include file, (very similar to the old behavior before the includes patch when the files were simply added to the end of the queue).
--- End quote ---
Thanks, yes, it works well (on my winXP system), so if no objections, I will commit this change.
--- End quote ---
I'm ok with committing this patch, can confirm it works fine on Win 7 / 8.
--- End quote ---
Thanks for the test.
--- Quote ---
--- Quote from: ollydbg on February 16, 2014, 03:00:30 pm ---
--- Quote ---The proper solution would probably be to ensure that the tokentree mutex is not accessed by the GUI while parsing, but this is not very easy.. lot of things the user does - mouse hover over a symbol, clicking into a function block, etc., will trigger the GUI to try access the mutex.. those are the times when I noticed the hangs actually.
--- End quote ---
The old behavior, when the parser is working, then gui access to tokentree was forbidden until parser finishes batch parsing, user will see some tips like "Parser is running, so no tip available". And later Loaden (one of C::B dev, but he was not active for years now) added many lockers to let the tree access from multiply thread.
So, do you think we need to change back to the old behavior? I hate those lockers. :)
--- End quote ---
We can try changing back to the old behavior, I don't see any reason to access the tokentree before parsing is finished (we don't display tooltips anyway). Is it this kind of check that we find in NativeParser::MarkItemsByAI()?
--- Code: --- if (!m_Parser->Done())
{
wxString msg(_("The Parser is still parsing files."));
msg += m_Parser->NotDoneReason();
CCLogger::Get()->DebugLog(msg);
return 0;
}
--- End code ---
--- End quote ---
Yes, m_Parser->Done() is the condition check to see whether Parser is currently working(parsing).
ollydbg:
--- Quote from: ollydbg on February 25, 2014, 07:49:21 am ---
--- Quote from: Huki on February 25, 2014, 07:44:50 am ---I'm ok with committing this patch, can confirm it works fine on Win 7 / 8.
--- End quote ---
Thanks for the test.
--- End quote ---
In SVN trunk now(r9665), it also includes a lot of code clean up, thanks for contribution.
Huki:
--- Quote from: ollydbg on February 28, 2014, 05:52:49 am ---
--- Quote from: ollydbg on February 25, 2014, 07:49:21 am ---
--- Quote from: Huki on February 25, 2014, 07:44:50 am ---I'm ok with committing this patch, can confirm it works fine on Win 7 / 8.
--- End quote ---
Thanks for the test.
--- End quote ---
In SVN trunk now(r9665), it also includes a lot of code clean up, thanks for contribution.
--- End quote ---
Thanks for the commit.. just one question about this change in Parser::OnAllThreadsDone()
--- Code: ---Index: src/plugins/codecompletion/parser/parser.cpp
===================================================================
--- src/plugins/codecompletion/parser/parser.cpp (revision 9664)
+++ src/plugins/codecompletion/parser/parser.cpp (revision 9665)
@@ -931,9 +888,7 @@
// Do next task
if ( !m_PoolTask.empty()
- || !m_BatchParseFiles.empty()
- || !m_PriorityHeaders.empty()
- || !m_PredefinedMacros.IsEmpty() )
+ || !m_BatchParseFiles.empty() )
{
TRACE(_T("Parser::OnAllThreadsDone(): Still some tasks left, starting m_BatchTimer."));
m_BatchTimer.Start(ParserCommon::PARSER_BATCHPARSE_TIMER_RUN_IMMEDIATELY, wxTIMER_ONE_SHOT);
--- End code ---
Was the "|| !m_PredefinedMacros.IsEmpty()" removed on purpose?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version