Closed webmaster128 closed 6 years ago
When both reading and writing 0, the attempts counter should be accessed inside of the start time mutex, to avoid race conditions. That said, have you considered just not resetting the attempts counter? It makes sense to me if at the 3rd key progress is 300%. It'd give you an overall progress vs an individual progress.
When both reading and writing 0, the attempts counter should be accessed inside of the start time mutex, to avoid race conditions.
I considered the case showing (attempts, start_time) where one is reset and the other is not for 250 milliseconds irrelevant. If you want to go that far and push for correctnes, we should have a struct (attempts, start_time) that is protected by a single RwLock.
That said, have you considered just not resetting the attempts counter? It makes sense to me if at the 3rd key progress is 300%. It'd give you an overall progress vs an individual progress.
I don't know if I understand correctly. All stats (estimated, keys, ratio, speed) are currently based on the current attempt and changing this is probably out of scope. Personally I have no interest in other limits than 1 and unlimted, in which case the overall progress makes no sense.
That said, have you considered just not resetting the attempts counter?
Ahh, now I get it. Interesting thought. No, I did not consider that. It would be a much simpler solution to #24
Just let me know which way you prefer. I'm fine with both
I'd prefer not resetting the attempts counter. I don't think there's a significant difference for the user, so let's stick with what makes the code simpler.
Here we go: #26
Closes #24