Revision ac0302e...
Go back to digest for 28th July 2013Optimization in Development Tools
Refactor the IProjectFilter interface for threading usage.
Instead of implementing the IProjectFilter interface, a plugin
now implements a IProjectFilterProvider interface. It comes with
a simple factory function to create a threadsafe IProjectFilter.
This is supposed to be used with value-semantics. All initialization
should be done in the ctor of its implementation, such that later
calls to isValid do not introduce any race conditions.
When a user changed any filters, the Provider emits a filterChanged
signal. Project managers and other users have to listen to it and
update their IProjectFilter instances then, i.e. replace their
existing instance with a new one as returned by createFilter.
This should now allow this interface to be used in the CMakeManager.
Furthermore it should be a future-proof design if we ever get around
to implement a proper API for threaded project import.
Note: If you think this design is complicated, then yes - the old
one was much simpler. This one has a huge advantage though of not
requiring any locks and thus leading to much better scaling when
we import from a background thread.
File Changes
- plugins/projectfilter/projectfilterprovider.cpp
- project/interfaces/iprojectfilterprovider.cpp
- project/interfaces/iprojectfilterprovider.h
- project/abstractfilemanagerplugin.cpp
- project/abstractfilemanagerplugin.h
- project/CMakeLists.txt
- plugins/projectfilter/CMakeLists.txt
- plugins/projectfilter/projectfilter.cpp
- plugins/projectfilter/projectfilter.h
- project/interfaces/iprojectfilter.h