Community
Participate
Working Groups
The ability to pause and resume jobs from the Progress View would be useful, especially for long running jobs that involving transferring content using protocols that support pause/resume. It could also be applied to Eclipse builds. Of course, not all jobs would support this so there would need to be API added that would allow the view to determine whether a Job was pausable or not and to pause and resume such a job.
There is sleep/wakeUp API on jobs, but it doesn't work for jobs that are already running. I considered this, but thought it was too high a barrier for job implementations to support it (they would need to capture and remember their current state in order to be able to pick up where they left off). Still, it's an interesting idea to keep in mind. One implementation approach would be for jobs to be able to declare that they are resumable. If resumable, a pause/resume button would appear in the progress view. Pausing the job would invoke Job#cancel(), and resume would invoke Job#schedule to restart it. It would be up to the job to pick up where it left off.
You would definitely want the job to declare that it was resumable, rather than require all jobs to support it. Kevin, this is the idea I talked to you about.
Perhaps another option would be not to cancel/reschedule a a pausable job, but just to block its execution. Obviously all the resources held by the job, will be still blocked while the job is paused, but the cpu and I/O consumption of the job would be 0. What I'm thinking about is the search jobs, which don't hold any locks (I suppose), but take a lot of I/O resources. I think it would be useful to be able to block the search (not just cancel it), in order to avoid disk trashing, for example for launching an application or other I/O bound jobs. Once the application is launched, the search can be resumed.
> Perhaps another option would be not to cancel/reschedule a a pausable job, but > just to block its execution. There is no safe way to do this in Java. The deadlock risk is too great. For example the thread may own some lock that the UI thread is blocked on, and there would be no way to resume it.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
The UI can't add any support unless the Job supports IResumable/ pause/resume methods. Is UI a right component for this bug or should I move it to Runtime?