MidiManager runs on the I/O thread, and use worker threads to run platform specific device operations that may need blocking operations.

In current design, we allows to access MidiManager instance from the worker threads, but it could introduce a race issue on MidiManager destruction. To avoid the race, MidiManager relies on midi::TaskService that provides a safe way to protect MidiManager during MidiManager methods run on another thread. But the TaskService required a condition variable wait call when MidiManager is going to be destructed on the I/O thread. This is not ideal, but the way we do today.

Background:
In the original design, midi::TaskService uses a rw-lock that wasn't assumed as a blocking call as lock operations were. But now that base/ does not provide rw-lock any more, and we needed to rewrite it with locks and a condition variable. At this point, waiting a condition variable was OK even on the I/O thread, but now it's asserted on debug build. This reveal the downside of the original design.

Plan:
Once we finish mojofication on media/midi, we'd try running whole MidiService on a dedicated thread rather than I/O thread. Or change MidiService to post all tasks to a dedicated thread that runs MidiManager. Thus we only need to call sync or block methods only on browser process shutdown there we are allowed to call them.