UI thread to build the symbol tree

[ollydbg]

I found that this function is running in a separate thread instead the main thread.

Code

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;
}

Does it safe to manipulate UI from a separate thread???

[Jenna]

On gtk the wxMutexGuiEnter and wxMutexGuiLeave should make it sure, why it is not used on other platforms, I don't know.
"very bad influence" as cause for not using it on windows is nor really an exact explanation.

[ollydbg]

thanks for the reply.
Also, I found a relative topic. see:
Re: Help on wxWidgets multi threading management

Edit:
see what wx developers said:
http://forums.wxwidgets.org/viewtopic.php?f=1&t=21037&hilit=wxMutexGuiEnter

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.

edit2:
I search on the c::b's source(include all the plugins source), the only place use "wxMutexGuiEnter" is here, I guess this is not a good design.

[Loaden]

Can we build the symbols tree on MAIN Thread?
Any comments?

[Jenna]

Can we build the symbols tree on MAIN Thread?
Any comments?

Building the symbols-tree can take several seconds and would block the main-thread every time it is rebuild.

[Loaden]

Can we build the symbols tree on MAIN Thread?
Any comments?

Building the symbols-tree can take several seconds and would block the main-thread every time it is rebuild.

But now there is a multi-thread-safety issues!
If we delete a Parser, but the symbol tree is still in the build process?

I can't find a better way for solved this issue.

[oBFusCATed]

You can use shared_ptr to prevent the deletion.

[Jenna]

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.

[Loaden]

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.
If more developers can focus CC plug-in, will be very lucky! :lol: