void* ClassBrowserBuilderThread::Entry()
{
while (!TestDestroy() && !Manager::IsAppShuttingDown())
{
// wait until the classbrowser signals
m_Semaphore.Wait();
// Manager::Get()->GetLogManager()->DebugLog(F(_T(" - - - - - -")));
if (TestDestroy() || Manager::IsAppShuttingDown())
break;
if (platform::gtk)
{
// this code (PART 1/2) seems to be good on linux
// because of it the libcairo crash on dualcore processors
// is gone, but on windows it has very bad influence,
// henceforth the ifdef guard
// the questions remains if it is the correct solution
if (!::wxIsMainThread())
::wxMutexGuiEnter();
}
BuildTree();
if (platform::gtk)
{
// this code (PART 2/2) seems to be good on linux
// because of it the libcairo crash on dualcore processors
// is gone, but on windows it has very bad influence,
// henceforth the ifdef guard
// the questions remains if it is the correct solution
if (!::wxIsMainThread())
::wxMutexGuiLeave();
}
}
m_NativeParser = 0;
m_TreeTop = 0;
m_TreeBottom = 0;
return 0;
}
i always considered wxMutexGuiEnter more like a hack. There is discussion among the wx developers to remove it completely.
I recommend not to use it.
Can we build the symbols tree on MAIN Thread?Building the symbols-tree can take several seconds and would block the main-thread every time it is rebuild.
Any comments?
But now there is a multi-thread-safety issues!Can we build the symbols tree on MAIN Thread?Building the symbols-tree can take several seconds and would block the main-thread every time it is rebuild.
Any comments?
You can use shared_ptr to prevent the deletion.and additional a flag, that marks the parser as invalid, so the symbolsbrowser buildthread (or possibly others that use the parser) stop using it.
This is a lot of trouble! Seems to be slowly improved.You can use shared_ptr to prevent the deletion.and additional a flag, that marks the parser as invalid, so the symbolsbrowser buildthread (or possibly others that use the parser) stop using it.