D14942: Connect new-image event to Scheduler imaging time estimator.

[Eric Dejouhanet]

TallFurryMan added a comment.


  In D14942#317187 <https://phabricator.kde.org/D14942#317187>, @wreissenberger wrote:
  
  > The fix is quite simple. Here is the patch:F6223164: looping.patch <https://phabricator.kde.org/F6223164>
  
  
  When I look at your patch, I don't readily understand how, at the point you target, `newFramesCount` could end up already assigned with a value that is different that what we are going to assign.
  So let's analyze.
  
  Map `newFramesCount` is empty at the beginning of the function.
  That map receives a value keyed by a signature when...
  
  - ...the map cache `capturedFramesCount` does not contain that signature as a key,
  - ...or for JOB_IDLE and JOB_EVALUATION states, for which we don't trust `capturedFramesCount` and want to recount.
  
  In those two situations, the algorithm calls `getCompletedFiles` to obtain the storage contents.
  
  Your patch essentially means it is possible for `capturedFramesCount` to have two different values for the same signature during a single run.
  That I agree on, but in order to fix the real issue, the question must be "//How is it possible for `capturedFramesCount` to end up with two different values during the run?//".
  
  The reason is, actually, that this function is relying on a cache: `capturedFramesCount` does not represent the current state of the storage, but is used to avoid the relatively high cost of `getCompletedFiles`.
  When jobs are evaluated, and one job triggers a recount because it is complete, `capturedFramesCount` will be refreshed with `getCompletedFiles`, and //that will introduce a discrepancy// for other jobs that were evaluated before.
  Depending on the evaluation order, sometimes we might see that discrepancy, sometimes not.
  
  I believe this is the root cause to fix, and I think your patch does not address that. What do you think?

REPOSITORY
  R321 KStars

BRANCH
  improve__scheduler_image_update (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D14942

To: TallFurryMan, mutlaqja, wreissenberger
Cc: kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20180829/35007197/attachment-0001.html>