Ensure thread-safety of ProgressReport models
Django models changes can be thread safe, but some care needs to be taken. We need the Progressreport models specifically to be thread safe.
This likely involves 2 things:
1. rewriting the implementaiton to be thread safe
2. Using documentation which identifies the thread-safety concern for plugin writers updating models themselves from many threads.
Updated by mhrivnak about 6 years ago
It is likely just the incrementing feature that needs to be thread-safe. The pattern will probably be:
- create a progress object
- create a Queue or similar
- create some threads and give them a reference to the queue, and probably the incrementor that comes with the progress object
- each thread runs in a loop: grab a job from the queue, do it, call queue.task_done(), and increment the progress object
- the main thread calls queue.join() and waits for the work to finish
It's worth considering if there's a way to either wrap or somehow hook into the queue's task_done method, but that's optional. There may not be a reasonable way to do so.
Updated by firstname.lastname@example.org almost 6 years ago
Based on the conversation on the above PR, it sounds like we only need to add some documentation that states that a single instance of a ProgressBar or ProgressSpinner objects should be used by all threads when processing items in parallel.
Updated by bmbouter almost 6 years ago
- Description updated (diff)
- Tags Documentation added
After some lunchtime conversation, it was confirmed that this is a documentation only change and that the docstrings should recommend the user have all threads share the same instance of ProgressBar. I don't think ProgressSpinner and ProgressReport need updates since updating those frequently will almost never occur.
I'm setting the documentation tag and rewriting the story some.