D15230: Fix cache discrepancy when a job is complete.

[Eric Dejouhanet]

TallFurryMan planned changes to this revision.
TallFurryMan added a comment.


  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.
  
  > - 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.

REPOSITORY
  R321 KStars

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/47d7e04c/attachment.html>