Bugzilla – Full Text Bug Listing
| Summary: | [api] task activity listeners should not called from the UI thread | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Shawn Minto <shawn.minto> |
| Component: | Mylyn | Assignee: | Shawn Minto <shawn.minto> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 247092 | ||
|
Description
Shawn Minto
Shawn: what's your suggested approach to resolving this? Removing those calls from the UI thread and expecting each listener to do its own asyncExec if necessary? (In reply to comment #1) > Shawn: what's your suggested approach to resolving this? Removing those calls > from the UI thread and expecting each listener to do its own asyncExec if > necessary? This was my initial thought. To do this though, the actions that invoke these methods will have to each run a job to perform their operations so that ordering is still maintained. It would be nice if the listener notification mechanism could do this, but then there is no guarantee that listeners are notified before the next operation is run. For example, the DeleteAction must deactivate the task, delete the task, delete the comment and close the editor. Deleting the task and context needs the task to be deactivated. If these actions are moved to a job, we will have to make sure that progress is properly displayed to the user so that they know that something is happening since jobs can be delayed in their running unlike the current implementation where it is just run in the UI thread. Let's look at this for 3.0 and make a decision whether or not to do this in the UI Thread. Using jobs for all notifications would come with a significant overhead that is unnecessary in most of the cases. Also most actions that are triggered by task activation, e.g. restoring of editors, focusing of views, need to run on the UI thread and should happen synchronously with activation. Shawn, you should be able to implement a queue of notifications if you need to process them in the correct order. Alternatively you can also use the workbench progress service if you want the listener to block further processing while a long running operation is running from a listener. +1 for leaving the current implementation Agreed. Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |