In the deconstructor of run_loop.cpp there is an assert that checks to make sure the Scheduler is null before setting it to null. In some rare scenarios where the app is being put into the background or closed the Scheduler can be null before the deconsturctor is called. This can cause an unnecessary crash. Since the goal here is to just set the Scheduler to null either way, it should not matter what the state of the Scheduler is before the function call.
Because a message we queue from the foreground may cause the background to complete, exit, and tear down the AsyncTask, we have to block queue processing until we've finished our call to AsyncTask::send().
Broadening the scope of a mutex is scary, but I audited the code of our four implementations of AsyncTask and I don't see any way this could cause a deadlock.
