Right now there's one mutex for the orchestration. I suspect that usually the scheduler will be holding that lock and thus client packets can't be processed. We should split this so we can process packets even while the scheduler is busy. We can also merge some packets together while the scheduler is running. For example we only care about the last UpdateByteRanges or SetConnectedPeers. UploadFailed's can be merged together.
The orchestration lock could process messages and stage everything, and then once the scheduler is ready process all of them and then dive into the scheduler again.
Right now we might process a single message and then run the scheduler again and create a huge backlog.
Right now there's one mutex for the orchestration. I suspect that usually the scheduler will be holding that lock and thus client packets can't be processed. We should split this so we can process packets even while the scheduler is busy. We can also merge some packets together while the scheduler is running. For example we only care about the last UpdateByteRanges or SetConnectedPeers. UploadFailed's can be merged together.
The orchestration lock could process messages and stage everything, and then once the scheduler is ready process all of them and then dive into the scheduler again.
Right now we might process a single message and then run the scheduler again and create a huge backlog.