Windows download hang

[adamlamar]

Overall, the high level design is something like:

• Run a new QThread using the BackgroundDownloader. Any slots invoked on the BackgroundDownloader are run on this new thread (not the UI thread)
• The ContentManager sends signals from the UI thread to the BackgroundDownloader thread.
• When needed, the BackgroundDownloader sends signals back to the ContentManager to confirm operations, such as starting or canceling a download
• The BackgroundDownloader::updateStatus() is invoked once per second by a QTimer, and updates the internal m_status map with information about the download
• The BackgroundDownloader:: getDownloadStatus() method can be called from the ContentManager on the UI thread to get the status of any particular download
• Since BackgroundDownloader can be called from two different threads, reading from the m_status map is protected by a ReadWrite lock

Fixes #87

[adamlamar]

getDownloadStatus() is called by ContentManager:: updateDownloadInfos(), which is running on the UI thread. m_rwlock protects the map read.

[adamlamar]

This parentless thread and call to moveToThread() is key to ensuring that BackgroundDownloader slots are invoked on their own thread that is separate from the UI thread.

[kelson42]

Hi @adamlamar. Have you given up on this PR? After the implementation of #921, nothing really blocks the completion here, do I'm right?

[kelson42]

@mgautierfr Its important to finally complete this PR.

[kelson42]

@adamlamar @veloman-yunkan @mgautierfr This PR which was containing quite a bit of work has been superseeded by #1038. Do we agree that this PR does not contain piece of code we should still merge to main and that we can close it unmerged?

[adamlamar]

Yep! Closing