Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

codecompletion plugin lead codeblocks crash, do GUI operation in worker thread

<< < (4/7) > >>

oBFusCATed:
ollydbg: The last patch does nothing interesting. Is it the only change that has to be made to C::B to fix the problem or other patches are required?

ollydbg:

--- Quote from: oBFusCATed on February 16, 2014, 07:04:38 pm ---ollydbg: The last patch does nothing interesting. Is it the only change that has to be made to C::B to fix the problem or other patches are required?

--- End quote ---
Yes, the patch is not mature.
It is kind of proof of concept to move those operations in GUI main thread.  ;D

oBFusCATed:
But if I understand you correctly you're moving all operations to the UI thread, because I don't see any data stored in the event's object.

ollydbg:

--- Quote from: oBFusCATed on February 17, 2014, 01:13:34 am ---But if I understand you correctly you're moving all operations to the UI thread, because I don't see any data stored in the event's object.

--- End quote ---
The function "void ClassBrowserBuilderThread::BuildTree()" is not called in "void* ClassBrowserBuilderThread::Entry()", but in "void ClassBrowser::OnBuileTree(cbBuildTreeEvent& event)".

The custom event(cbBuildTreeEvent) just carry a "ClassBrowserBuilderThread* thread" from the worker thread to main GUI.

oBFusCATed:
OK, but how do you know how many elements you have to add to the tree in a single event handler? As far as I see it you still need locking.

If I'm doing this I'd rather:
1. in the parser thread generate some data and store it in the symbolbrowser event object
2. post an event with the gathered data
3. continue with parsing
4. when I receive the event I'll add the data to the tree

This way it is explicitly stated how owns the data exclusively and there is no need for locking.

Navigation

[0] Message Index

[#] Next page

[*] Previous page