At this point, MidiManager is designed to run on multiple-threads, and to live forever until the browser is going to be shutdown.
This design has two big problems.
1. All platform dependent implementation need to consider multi-threading on the browser main thread and I/O thread carefully.
2. It's hard to destruct and re-construct MidiManager
And, we have two use cases for the problem 2.
1. Destruct MidiManager when no clients use it (for a battery-life concern)
2. Dynamic backend switch on Android and Windows (because new backends seem to have user-environment dependent problems, and need switching to fail-safe backend)
New design idea is
- BrowserMainLoop owns MidiService (would be a mojo service eventually)
- BrowserMainLoop is instantiated on the browser main thread
- Platform dependent part is implemented as a MidiManager (as we do now)
- But the new MidiManager run only on the I/O thread, that means MidiService would lazily instantiate it on the I/O thread.
- MidiService would destruct the MidiManager when all clients are detached, and reconstruct another MidiManager when it is requested again.
Comment 1 by toyoshim@chromium.org
, Dec 9 2016Labels: -Pri-3 Pri-2
Owner: toyoshim@chromium.org
Status: Assigned (was: Untriaged)