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

Wolfgang Reissenberger noreply at phabricator.kde.org
Wed Aug 29 18:40:25 BST 2018

wreissenberger added a comment.

  Hm, I think the reason is the strategy how the cache is updated and not a pure invalid cache problem.
  Lets consider Job A and Job B having both the identical signatures with one Luminance frame, Job A starts before Job B, both run in two cycles. As a result of Job A finishing (if Job A does not get into trouble), we would expect `Lum-001.fits`and `Lum-002.fits`.
  Now let's see what happens if the **first** of the two cycles of A is finished. Job A has produced `Lum-001.fits` and returns to `evaluateJobs()` which calls `updateCompletedJobsCount()`. The latter one cycles over all sequence jobs. When it passes Job A (remember, it's the first one in the list), which is in the state JOB_EVALUATION, it calculates
    newFramesCount["...Lum"] = getCompletedFiles("...Lum", ...) = 1
  After this, Job B is evaluated for the same signature `"...Lum"`, but it uses another branch in the loop and takes the cached value
    QMap<..> sigCount = capturedFramesCount.find("...Lum")
    newFramesCount["...Lum"] = sigCount.value() = 0
  Since capturedFramesCount gets updated only after **all** sequence jobs have been evaluated, it takes the old value from the run before.
  So we need a solution how the cache is updated accordingly. I think my solution is not bad, since it takes the maximum of the (old) cached value and a fresh calculated value. The alternative is avoiding cache access during the cache update completely.

  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/9f1fd7d0/attachment.html>

More information about the kde-edu mailing list