This was causing a race condition where the "absurdly large aux buffer"
panic alert would be triggered in the last bit of fifo processing on the
CPU thread in deterministic mode (i.e. netplay). SyncGPU is supposed to
move the auxiliary queue data to the beginning of the containing buffer
so we don't have to deal with wraparound; if GpuRunningState is false,
however, it just returns, because it's set to false by another thread -
thus it doesn't know whether RunGpuLoop is still executing (in which
case it can't just reset the pointers, because it may still be using the
buffer) or not (in which case the condition variable it normally waits
for to avoid the previous problem will never be signaled). However,
SyncGPU's caller PushFifoAuxBuffer wasn't aware of this, so if the
buffer was filling at just the right time, it'd stay full and that
function would complain that it was about to overflow it. Similar
problem with ReadDataFromFifoOnCPU afaik. Fix this by returning early
from those as well; other callers of SyncGPU should be safe. A
*slightly* cleaner alternative would be giving the CPU thread a way to
tell when RunGpuLoop has actually exited, but whatever, this works.
Core::Shutdown was only called on app exit, yet the emu thread exits
whenever emulation stops; if you launched a new game it would just join
via the destructor when s_emu_thread was set to a new thread.
(Incidentally, the destructor also makes explicitly joining on app exit
rather pointless.)
Because the GUI thread wasn't waiting for the CPU thread to fully shut
down, Core::IsRunning would remain true briefly after CFrame::DoStop
which, given Dolphin's penchant for accessing variables belonging to
other threads, can only mean trouble... In my case, because the previous
commit caused UpdateGUI, which is called at the end of DoStop, to call
PauseAndLock, which checks IsRunning, pressing stop at the right time
would cause strange behavior.
Since its lifetime is managed on the CPU thread, this (or a refactoring)
is absolutely required. One of the functions with a PauseAndLock call
added is CFrame::UpdateGUI; this is fine now, since it's called only
after important events happen, so just make sure not to call it every
frame or something :)
Initially, the dialogs construct in the background when Dolphin initializes. However, it waits until the user actually makes the dialogs visible to decide on whether to create the Wii or GC control layouts.
Therefore, the call to CreateBaseLayout() essentially creates a sizer that isn't actually attached to a main sizer that is set as the sizer for the dialog to use. So upon destruction, these controls would never actually be destroyed if the user didn't open and then close the TAS dialogs.
Incrementing the reference count here isn't necessary, as they construct with a count of 1. Incrementing again results in the attributes not being freed.
