D15230: Fix cache discrepancy when a job is complete.

[Wolfgang Reissenberger]

wreissenberger added a comment.


  In D15230#319940 <https://phabricator.kde.org/D15230#319940>, @TallFurryMan wrote:
  
  > In D15230#319479 <https://phabricator.kde.org/D15230#319479>, @wreissenberger wrote:
  >
  > > Looks good, my test cases with the duplicated schedule are running now. Two minor things that I found, but they are not critical:
  > >
  > > - Having two jobs with the same signature both with `FINISH_REPEAT`and the second to run has less cycles than the first one, the second is started and finishes after one iteration. But I think this not a behavior introduced with this fix. Just to be mentioned...
  >
  >
  > Ah, yes. Probably a regression or a side-effect of an older change. This use case is a bit weird (but possible of course), perhaps we should order duplicates per repeat count?
  >  Also, I'm weighting the possibility to reorder the jobs in the list per startup order, so that it's clearer for the end-user which one will start before the other.
  
  
  This happens also if you have two identical cycle numbers. The second one starts once and detects after one cycle that it is completed. It seems like there is no check that jobs once scheduled might get completed without a single run.
  
  > 
  > 
  >> - When creating `newFramesCount`there is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to `getCompletedFiles()`. Functionally this is OK, but it makes the check slower.
  > 
  > Agreed. Perhaps I can add a check right now.
  
  OK, checked, working.

REPOSITORY
  R321 KStars

BRANCH
  bugfix__capture_cache_invalidate (branched from master)

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

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