BITS spins up multiple threads: a command thread, and a monitor thread per request. If there aren't any strict ownership requirements (like, a job must be bound to a specific thread), could we migrate these to use background tasks and task queues instead?

As currently designed, the monitor threads don't do well sharing a thread, which is why one is spun up per request. The monitor threads monitor the BITS job via polling. In order to rate limit the polling, they block until the polling interval elapses. This means that anything else that shares a thread with these jobs will potentially spend a lot of time waiting on the monitor job.

This polling is used to update the progress bar shown when Firefox is downloading an update. So if the monitor threads have to wait too long to execute (I don't know how big of a concern that is), then that progress bar may update in a jerky fashion.

Cool, thanks so much for the explanation! If we bump up the thread pool size, we shouldn't have to wait too long between polls...but you're totally right, if the pool is under heavy load, we risk either janking the update progress bar, or blocking other I/O tasks scheduled on the same pool. And the monitor threads are short-lived, while many other callers that spin up dedicated threads keep them around until shutdown. This might end up being a WONTFIX—in which case we'll want to keep create_thread around—but I wanted to file the ticket just in case.