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

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

<< < (5/7) > >>

ollydbg:

--- Quote from: oBFusCATed on February 17, 2014, 01:25:07 am ---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.


--- End quote ---
OK, I understand you idea, but we are not talking with the same lockers.
You are stating the locker for the TokenTree, but my patch try to move the build wxTreeCtrl code from worker thread to GUI thread.

Note, TokenTree locker is still there, but mostly they don't cause issue, because the wxTreeCtrl is mainly constructed after the Parser finish the job, in that time, TokenTree is always free(not owned by other one).

Back to your proposed method, to avoid the TokenTree locker when building the tree, you need to construct some data structure (some kind of a copy of a sub Tokentree?) and send to the GUI thread, but if the data structure is too large?

MortenMacFly:
First of all the patch does not work but crashes cb at exit. Second if the data gets too large you can use a pointer. Third I don't think it's that easy.Yes, the method is called from outside but the task is still operated in the thread so it doesn't really change anything... Sorry.

ollydbg:

--- Quote from: MortenMacFly on February 17, 2014, 06:13:19 am ---First of all the patch does not work but crashes cb at exit.

--- End quote ---
Hi, Morten, thanks for the test. In-fact, If we need to build the Tree from GUI, we should totally remove the worker tree builder thread stuff.


--- Quote ---Second if the data gets too large you can use a pointer.

--- End quote ---
Yes, just as the same way as we access to Tokentree to query suggestion list information.


--- Quote ---Third I don't think it's that easy.Yes, the method is called from outside but the task is still operated in the thread so it doesn't really change anything... Sorry.

--- End quote ---
The tree build thread is large, also, I read some comments in the code like:

--- Code: ---// 9.) Expand item --> Bottleneck: Takes ~4 secs on C::B workspace
....
// 11.) Select the item saved before --> Bottleneck: Takes ~4 secs on C::B workspace

--- End code ---
I won't let the GUI to hang for 8 seconds, so I won't step further in this direction for now.  :)

kipade:
Hi All, thanks for all attention about this topic. I wanna say, the simple code was just a test for that, just to see if this can fixed the crash bug, a joke.
Yes, if need finally perfect fix for that issue, some more slight design for that might needed. Of course we can drive a tree control from wxTreeCtrl, it seems more familar with OO rule. But, there still have some other choices such as my moved BuidTree. I think, if all the operations could be separated with data, and GUI, one class only do which it should, all the things become easy. I think.
If it still no official support, I might continue to complete it by my hand, because I need it work under linux. Any idea is welcome.

ollydbg:

--- Quote from: kipade on February 17, 2014, 04:08:31 pm ---If it still no official support, I might continue to complete it by my hand, because I need it work under linux. Any idea is welcome.

--- End quote ---
Do you think it is definitely the codecompletion's browser tree which cause the crash issue?
I haven't seen that on our forum about such issue, can you show us the crash backtrace?

Navigation

[0] Message Index

[#] Next page

[*] Previous page