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

Eric Dejouhanet noreply at phabricator.kde.org
Wed Aug 29 14:48:52 BST 2018

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?

  R321 KStars

  improve__scheduler_image_update (branched from master)


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>

More information about the kde-edu mailing list