I didn't know that telling that you don't schedule from the CPU thread prevents an assert because it by default assumes you use the CPU thread, but in the case of ClearCacheThreadSafe, it's used from the GUI thread.
Commit 4969415 modified calls to GetInterpolationQualifier, but mistakenly changed the order of some boolean parameters: GetInterpolationQualifier(true, false) was changed to GetInterpolationQualifier(…, false, true).
Should fix#9783.
Currently, `g_controller_interface` is initialized and shut down by each
of `GCKeyboard`, `GCPad`, `Wiimote`, and `HotkeyManager`.
This 1) is weird conceptually, because it necessitates passing a pointer
to the native window to each of those classes, which don't need it, and
2) can cause issues when controller backends are initialized or shutdown
multiple times in succession.
For Wii graceful shutdown to work, the emulated software has to open
the STM event hook and install a hook. Without this, there is no way
to inform them about the shutdown, so trying to do a graceful shutdown
and requiring the use of the shutdown fallback (exiting a second time
to force) is pointless.
Previously Dolphin would only exit if the main window is closed,
and Confirm on Stop is enabled.
This makes Dolphin's behaviour more consistent by always exiting
if the main window is closed or on shutdown signal.
s_dvd_thread_done_working makes the logic more complicated,
and degasus pointed out a race condition that can happen if
the CPU thread calls WaitForIdle right in between the DVD
thread executing done_working.Set() and done_working.Reset()
while there is work left to do. To avoid this, let's just get
rid of s_dvd_thread_done_working. It's a relic from the old
DVDThread design. Thanks to the last few commits, WaitUntilIdle
only gets called rarely (disc change and savestate), so it's
not a problem if WaitUntilIdle ends up being slower.
This is a preparation for adding a queue to DVDThread.
Currently, s_read_request and s_read_result act somewhat like
queues that only can contain one object.
This would previously fail to compile when included in files that do not
include FileUtil.h due to lack of a type declaration.
This moves the constructor and destructor into the cpp file in order to
satisfy the requirements of unique_ptr construction and deletion. That is,
unique_ptr requires a concrete type at the point of construction and
destruction. If the constructor or destructor is left in the header, then
at the point of construction or destruction, IOFile will still be
considered an incomplete type, as unique_ptr's deleter will still only be
able to see the forward declaration, which it can't use.
Unless I'm misreading the code, it doesn't look like this serves any
purpose, and is only polluting the logs.
_Unimplemented_Device_ looked like a device name that was picked to
be used somewhere else in Dolphin, but this doesn't seem to be the case
since 2012 (d95e31a removed the only other usage of this fake device).
