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

parser test rev 7157 error?

<< < (5/7) > >>

Loaden:

--- Quote from: ollydbg on May 27, 2011, 02:45:30 pm ---CC search for tip should only works when there is NO batch parsing.
Are there any state variable indicate that batch parsing is running?

--- End quote ---
You can open the CB workspace, and open some project, then worked on first batch parsing project.
You will catch the case.

You can do call tip search, or other local buffer parsing, but another (one or many) is still running.
If any one have good idea, pls let's me know.

ollydbg:
@loaden, if a workspace contains many projects, and you use only ONE TokensTree for all the cbps, this could be a big issue.

Because the TokensTree is the only resource we should take care.
Every Token collected from the batch parsing was recorded in this TokensTree. So, even some projects are already parsed, there are still projects remaining working and adding Tokens to TokensTree. In the mean while, if you do some search algorithm on the TokensTree, there may be some access conflict.

oBFusCATed:
Just to note:
The general principals:
1. Shared state/resource should be protected, so only one thread could access it.
2. Protecting (locking) the share state/resource should be done for minimal periods of time. To implement this most of a time something like this can be used:


--- Code: ---// do some processing on a temp var;
MySharedResource temp;
temp.process();
mutex.lock()
shared.swap(temp);
mutex.unlock();

--- End code ---
3. Using hacks == pain! Don't do it!

You need to identify the shared state and protect it in the best possible way!

Loaden:

--- Quote from: ollydbg on May 27, 2011, 03:04:46 pm ---@loaden, if a workspace contains many projects, and you use only ONE TokensTree for all the cbps, this could be a big issue.

--- End quote ---
No, In current use one parser per one TokensTree.
But there still exist thread-safe issue.
Include the symbols browser.

Loaden:

--- Quote from: oBFusCATed on May 27, 2011, 03:12:01 pm ---Just to note:
The general principals:
1. Shared state/resource should be protected, so only one thread could access it.
2. Protecting (locking) the share state/resource should be done for minimal periods of time. To implement this most of a time something like this can be used:
3. Using hacks == pain! Don't do it!

You need to identify the shared state and protect it in the best possible way!

--- End quote ---
Thanks, I know that, but I can't find another place need protected again.
oBFusCATed , If you have some time, could you help me check the Parser of CC?

Navigation

[0] Message Index

[#] Next page

[*] Previous page