On 2013-09-03, at 18:57, Stephan Eggermont <[email protected]> wrote: > Camillo wrote: >> in this case it is only the instance of Job which knows the status. >> Thread-safeness is not an issue since the progress bar is pure >> approximation. > > The problem is not approximation. Objects are not reentrant, getting the value > out of a model while it is reorganizing its datastructure is likely to give > interesting > and difficult to reproduce results (dividing by 0, nil-pointer exceptions). > >> that does not work properly and inaccurately reports long running jobs, for >> instance >> when running tests. Usually tests take far less than 1 ms, in which case >> this scheme >> works perfectly. However from time to time you have 1 test that runs for a >> couple of >> seconds. If you run 5000 tests you have to run quite a few tests to get that >> 1% update >> margin, so very often the UI does not correctly report the current status. > > That is not a solvable problem. A progress bar depends on a value increasing > from > min to max. The model is responsible for making reasonable steps.
ok, different question, how do you solve this very use-case without polling? 1. run test 1 [1ms] ..... N. run test N [1ms] ------------------------------------------- Progress Bar update limit reached after a) either N update calls b) N ms => next update will happen in a) N calls b) N ms ------------------------------------------- N+1. run test N+1 [1000 ms] That means that the UI shows the wrong value (run test N) instead of the current progress value (run test N+1), which is not interesting. The model, in this case the test runner, properly informed the UI about every change, but the update limitations in the ProgressBarMorph cannot properly detect such a case. - either you update way to often => performance overhead - or you update not often enough => inaccurate progress indication when progress step times differ a lot There is simply no way you can properly solve this case without active polling. As for your doubts about thread-safeness: The model for the ProgressBar is the Job class. It is hence the only entry point for the PogressBar and thus can easily be made threadsafe. My use-case is simply that I want to see in which test-case the test runner hangs.
signature.asc
Description: Message signed with OpenPGP using GPGMail
