We don't need a separate worker thread. I already have an idea in my mind how such a reactive, event-loop-driven TrackActionScheduler can be implemented efficiently:
- shared queue of pending track ids
- queue of pending actions: action functor working on a single TrackPointer, number of total tracks, number of finished tracks
Some parts of the new TrackAnalysisScheduler might be reusable.
We don't need a separate worker thread. I already have an idea in my mind how such a reactive, event-loop-driven TrackActionSche duler can be implemented efficiently:
- shared queue of pending track ids
- queue of pending actions: action functor working on a single TrackPointer, number of total tracks, number of finished tracks
Some parts of the new TrackAnalysisSc heduler might be reusable.