Community
Participate
Working Groups
At https://git.eclipse.org/r/#/c/21660/ Eike says: It's very nice that with SubMonitor the done() method not always needs to be called, but I think when it is called and leaves a non-zero work delta then done() should be called on the root monitor, too. The reason why I stumbled about this is that I developed an wrapper around SubMonitor that can be instrumented to collect and dump various statistics about the usage of the SubMonitor, such as number and locations of child creation, time spent in children or between worked() calls and so on. Some of these child-related statistics require that done() is properly called on the root monitors so that they can finish their summary of the measures. I found that the small changes in this patch make it work perfectly for me, but I must admit that I can't foresee all possible implications and consequences. Hopefully there are none. If it helps you to play with an example I can certainly put together a small project with code that you can execute.
I think John would have to review this one.
I fear I have to withdraw the current patch set. I found that with my change progress is no longer reported correctly. For example in a ProgressDialog the progress bar doesn't even show up, probably because progress gets lost somewhere on the way up. I'll continue to play with it. Maybe one of you expert guys have an idea how to solve my original problem correctly?
Okay, I must apologize because I didn't study SubMonitor enough. Now I understand that it all nested instances really wrap a single root monitor and not nested parent monitors. Of course it's not correct to call done() on that root monitor prematurely. What I'm really interested in is to intercept the done() call of a (possibly nested) SubMonitor, not of its root monitor. Of course that isn't possible because SubMonitor is declared as final. You're not willing to remove this constraint, eh? BTW. I don't understand why there's a need for an extra heap object for the RootInfo. It seems as if there's an exact one to one relation between a SubMonitor and its RootInfo instance. That could probably be implemented more efficiently, which seems relevant for progress monitoring. I'm closing this bug as worksforme because there's not much that you can do for me, except removing the final modifier from SubMonitor. Sorry for the noise.
Created attachment 239761 [details] ProbingProgress (Net4j Utilities Documentation).pdf I wonder if you are interested in having my functional additions to progress monitoring, especially the transparent instrumentation for automatic measurements directly in your SubMonitor class. It would involve no cost at runtime if I rework it to be more pluggable. I attach the documentation of my ProbingProgress monitor so that you get an idea of what it can do.
(In reply to Eike Stepper from comment #3) > BTW. I don't understand why there's a need for an extra heap object for the > RootInfo. It seems as if there's an exact one to one relation between a > SubMonitor and its RootInfo instance. That could probably be implemented > more efficiently, which seems relevant for progress monitoring. That was silly, too. Please assume that I never said that ;-)
(In reply to Eike Stepper from comment #4) > I wonder if you are interested in having my functional additions to progress > monitoring, especially the transparent instrumentation for automatic > measurements directly in your SubMonitor class. It would involve no cost at > runtime if I rework it to be more pluggable. I attach the documentation of > my ProbingProgress monitor so that you get an idea of what it can do. I've prepared prototypes here: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/om/monitor/SubMonitor.java http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/om/monitor/ProbingSubMonitor.java An overview of the changes to the existing SubMonitor code: - The new class is no longer final because ProbingSubMonitor extends it. Instead all methods except done() and worked() are final. The constructor is now package private. - The "root" field is now package private because ProbingSubMonitor uses it, too. - The "flags" field is now package private and no longer final because ProbingSubMonitor uses it, too. - I've added the following public methods: - static convert(IProgressMonitor, ProbingMode) - static convert(IProgressMonitor, int, ProbingMode) - static convert(IProgressMonitor, String, int, ProbingMode) - detectCancelation() - detectCancelation(boolean) - worked() - skipped() - skipped(int) - newChild() - childDone() I would appreciate your feedback regarding these changes. If you like them I'd be happy to contribute them to the SubMonitor in equinox.common. Of course I could just keep my "enhanced" copy of your SubMonitor but: 1) Because of the different instanceof checks in both versions of SubMonitor.convert() having only one version of the class is preferrable. 2) I found that especially the automatic cancel detection and the automatic measurement of the time being spent in/between the various SubMonitor methods can be very helpful for many people. The reporting of the measures would have to be made more configurable.
It sounds like you guys are working on the same thing here that I was exploring in bug 482062. I'd suggest we combine efforts.
