For a progress indicator, an off-by-one caused by insufficient locking
does not matter.
I don't know how the threads could measure their progress. But simply
incrementing a global variable (common to all threads) allowing a
"progress-reporting-thread to inspect it and report it.
The "no locking" would mean you'd get an occasional off-by-one. (thread loads
variable into CPU, increments it, other thread also increments it and first
thread stores the result it incremented. Now one of the increments has been
lost. As long as you spend say less than 1/1000th of the time
incrementing the counter, you are going to lose less than 1/1000th of the
counts. Still totally unacceptable if it causes the program to hang, e.g.
waiting for the counter to reach the end. But for progress reporting to the
user: just fine.
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
icpfind reports progress every 250 cross matches.
Status in Hugin:
This is just fine for my current projects. For small projects it might
update slightly too fast (too much useless overhead in painting the
screen) while for a large project it goes a bit slowly.
This means that it depends on the size of the project how fast the
updates come. But most of all the updates depend on how fast my CPU
is. To make the software future proof, we should make it for example:
- set a timer to go off twice a second.
- in the timer set a flag.
- in the mainloop (e.g. every 1, 10 or 50 matches) check for the flag and
print the progress if set. Reset flag.
(this is the most sure-fire way to prevent IO concurrency problems. ).
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~hugin-devs
Post to : email@example.com
Unsubscribe : https://launchpad.net/~hugin-devs
More help : https://help.launchpad.net/ListHelp