| |
| |
| Basic concurrency use cases. Some are overlapping, but each requires |
| a different level of concurrency support. Roughly ordered by perceived |
| implementation difficulty. 1. and 2. are currently support in Eclipse 2.1, |
| but we need to keep them in mind with any new story. |
| |
| 1. Allow decoration tasks to continue in background without affecting |
| UI responsiveness or ability to modify resources. |
| |
| Examples: |
| a) User performs a CVS update. While CVS is computing and updating |
| new decorations in various views, the user wants to continue viewing |
| and modifying resources. Duplicate decoration work should be detected |
| and avoided (don't decorate the same resource twice if possible). |
| b) User is typing in an editor. Computation of effects such as |
| "red sea", and bracket matching should happen in the background |
| without affecting responsiveness. |
| |
| 2. Very long running operations that do not modify resources, but must |
| be stoppable, and joinable. |
| |
| Examples: |
| a) User imports a JAR file. This triggers an indexing job in the background. |
| User can continue to view and modify resources while indexing happens. |
| If the user deletes the JAR, or modifies it, duplicate or superfluous |
| background jobs should be canceled automatically. |
| b) User imports a JAR file. This triggers an indexing job in the background. |
| User then requests a type hierarchy. Priority of any index jobs |
| required by the type hierarchy should be bumped up and completed |
| immediately. |
| |
| 3. Allow browsing during long operation |
| |
| Example: |
| The user has started some long running background task (checkout, |
| import, build, etc). They want a live UI so they can browse resources |
| (get children, get contents, dirty editors) while they wait for the long |
| operation to finish. |
| |
| Deluxe: |
| The background task can complete in chunks, allowing the user to browse |
| and modify resources that were involved in the operation. I.e., they |
| can edit imported resources before the import has completed. |
| |
| 4. Allow edit during long running read-only operations |
| |
| Example: |
| The user starts a search. Since searches don't modify resources, |
| the user may want to modify (add, delete, change) resources while |
| the search is happening. This may or may not affect the search |
| results. |
| |
| 5. Concurrent edit. |
| |
| Examples: |
| a) The user does a CVS update on project A while project B is being deleted. |
| b) The user does a CVS update on project A while that same project is |
| being compiled, deleted, etc. This is the extreme concurrency example. |
| |
| |
| 6. Allow preemption and restart on long-running operation. |
| |
| Examples: |
| a) The Mcq example. User hits save on a file, and build starts. User |
| realizes that there is an error, and they modify and save again. |
| They want to cancel the currently running build and start a new one. |
| b) User selects a revision in the CVS repositories view, and hits |
| checkout. While checkout is running, user realizes they chose |
| the wrong version, and they want to checkout a different one instead. |
| They want to cancel the current checkout and pre-empt with another. |
| |