Week 3 Report: June 12th to June 18th
- Not much progress due to heavy oncall load at work.
- @iss did some preliminary PR review and found a bug where we couldn’t push new files to the PreviewJob due to the TaskPoll work and wait call.
- Read through the TBB thread_group documentation to see if they had any way to just poll the thread group. TBB is the library that backs Blender’s TaskPool implementation. No luck with polling.
- Read through other Blender code to see how things were done (thanks @iss for the suggestion). These are the files I went through:
- Updated PR with a new commit that uses a ThreadCondition variable to notify the PreviewJob when new audio jobs are added to the queue. This fixes the previous issue somewhat, but there’s still a chance where the PreviewJob is terminating but a new audio job gets added to the queue. In this case the audio job will leak because it isn’t caught by the PreviewJob. The same thing can happen with the code we have in
main
, but it might be unlikely to be hit due to how slow processing each file is and the serial processing of each item in the queue.
Demos
These demos are recorded with a release build.
Multiple files in parallel
Adding new files while others are being processed
Note: progress bar updates work just fine with this implementation and accounts for new files being added.
Next steps
Figure out how to deal with the race condition mentioned.
Two possible approaches are:
- Never terminate the preview job and just let it block on the ThreadCondition variable.
- Add some state flag to the preview job (like
bool terminating;
): When the flag is truesequencer_preview_add_sound
keeps waiting until the job is done. It then creates a new preview job.