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

[Wolfgang Reissenberger]

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.

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