Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

question about running parser in thread

<< < (2/2)

ollydbg:

--- Quote from: MortenMacFly on January 05, 2014, 10:54:53 am ---
--- Quote from: ollydbg on January 04, 2014, 07:39:28 am ---You see in the function: m_NativeParser.GetParser().Done(), there are dirty lockers

--- End quote ---
What happens, if you remove those lockers? They may not even be needed (assuming atomic functions for .empty() etc...)

--- End quote ---
std::list<wxString>::empty() is atomic? I don't think so.

Only cbThreadPool::Done() is atomic as I can see.


--- Code: ---inline bool cbThreadPool::Done() const
{
  wxMutexLocker lock(m_Mutex);
  return m_workingThreads == 0;
}

--- End code ---

Anyway, the GUI hang issue mostly happens by a local patch of Huki cc_includes_parsing.patch.

Would you mind to show some comments on how we can handle those kind of lockers? (I hate those lockers :), one reason is that wxString in wx2.8 is too bad for a multiply thread application, second reason is those locker code make the source a bit hard to read and understand, third reason is they have some issue to cause GUI hang.......)


About the issue you said:

--- Quote from: MortenMacFly on January 03, 2014, 04:16:19 pm ---
--- Quote from: ollydbg on January 03, 2014, 04:05:05 pm ---Maybe, in this case, another working process is better than working thread?

--- End quote ---
I always suspect its the call of the compiler to get #defines and stuff like that.

--- End quote ---
To solve this, we can put this step to a worker thread or a worker thread task(Our Parserthread class is not a thread, but a task witch can executed in the thread pool). This should avoid the GUI hang when batch parsing started, because it is currently done in the event handler(wxTimer handler) of the GUI.

Navigation

[0] Message Index

[*] Previous page