Community
Participate
Working Groups
Currently it is possible to split a monitor using SubMonitor class, while this works good in a linear workflow, it does not work well in distributed flows where each item want's to report progress independently. Another drawback is, as the original progress monitor has no way to know about the split it is not possible to handle this in a user-friendly fashion e.g. it is not possible for a User-Control to show the progress independently. To overcome this limitations a new way of slicing a monitor is suggested: - add a (default implemented) 'IProgressMonitor slice(int work)' method - the returned monitor behaves as if one has created a fresh instance with the given amount of work (that implies that the caller of slice(...) is responsible to call "done" on the returned monitor if no longer needed) - whenever a full work unit is reported on the slice it is propagated to the parent - it is safe to use slices in another thread - it is possible to create more than one slice without influence the others
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/170662
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/170662 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=87dc8dec2f5c5ecf754dd0fe744f1b4e33785546
We should add a new and noteworthy entry for this.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/171728
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/171728 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=17b2e79566cad65290642e1aac9caf4df78fc00d
That'I just stumbled upon this addition when working on the noteworthy doc for another issue, and I'm pretty happy to see it added; I'm quite happy to see this implemented, I had need for it in the past and never really formalized it in a bug. Now that we have this available, should we consider deprecating the SubMonitor class; and/or at least add a link to SubMonitor to this new slice(...) method that should usually be preferred?
(In reply to Mickael Istria from comment #6) > That'I just stumbled upon this addition when working on the noteworthy doc > for another issue, and I'm pretty happy to see it added; I'm quite happy to > see this implemented, I had need for it in the past and never really > formalized it in a bug. > > Now that we have this available, should we consider deprecating the > SubMonitor class; and/or at least add a link to SubMonitor to this new > slice(...) method that should usually be preferred? I'm not sure we should deprecate, but a reference to the slice to indicate it may be more appropriate for many scenarios would be useful I think.
@Mickael I copy some code from the gerrit review [1] here, maybe the N&N entry needs improvement to make it more clear, I just find it a bit hard how much to explain there without bore people, so if you think something should be added/clarified feel free to enhance the entry :-) There was the following question (and my answer below) I hope this makes it more clear (no idea how to link to comments in a gerrit) > Just looking over the differences between what IProgressMonitory.split > does vs what SubMonitor does start to confuse me. Why do we need both? [ ...] 3) They can be used in conjunction, e.g. one can use slice(...) to distribute work (e.g. with streams) and use SubMonitor to delegate to sub-method calls. But you are right, both share a lot of common code and concepts (as many other classes that try to solve different progress monitor stuff). [...] [1] https://git.eclipse.org/r/c/equinox/rt.equinox.bundles/+/170662
(In reply to Thomas Watson from comment #7) > I'm not sure we should deprecate, but a reference to the slice to indicate > it may be more appropriate for many scenarios would be useful I think. I think one can best distinguish between both by taking the following in mind: 1) SubMonitor.split() is used to *divide* progress e.g. for method calls. 2) IProgressMonitor.slice() is meant to *distribute* progress, e.g. for concurrent work in background threads. There is one major difference to take in mind: 1) SubMonitor.split() completes the previous monitor and can reuse unconsumed ticks. 2) IProgressMonitor.slice() does not complete automatic and the caller of slice() is reponsible for doing this, unconsumed ticks can not be reused.
(In reply to Christoph Laeubrich from comment #9) > (In reply to Thomas Watson from comment #7) > > I'm not sure we should deprecate, but a reference to the slice to indicate > > it may be more appropriate for many scenarios would be useful I think. > > I think one can best distinguish between both by taking the following in > mind: > 1) SubMonitor.split() is used to *divide* progress e.g. for method calls. > 2) IProgressMonitor.slice() is meant to *distribute* progress, e.g. for > concurrent work in background threads. > > There is one major difference to take in mind: > 1) SubMonitor.split() completes the previous monitor and can reuse > unconsumed ticks. > 2) IProgressMonitor.slice() does not complete automatic and the caller of > slice() is reponsible for doing this, unconsumed ticks can not be reused. OK, that make sense to add it in the doc with something like @see IProgressMonitor.slice() if the goal is to distribute the work to different executors, typically in a concurrent way.
