|
What this is
Other links
The source codeBasic 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. |
... this post is sponsored by my books ... | |
#1 New Release! |
FP Best Seller |
Copyright 1998-2021 Alvin Alexander, alvinalexander.com
All Rights Reserved.
A percentage of advertising revenue from
pages under the /java/jwarehouse
URI on this website is
paid back to open source projects.