Implemented sys_game_watchdog syscalls

[brian218]

I implemented three sys_game_watchdog syscalls (sys_game_watchdog_start, sys_game_watchdog_stop, and sys_game_watchdog_clear) as a few games seem to rely on the watchdog to reboot the game itself.

[brian218]

Needs more suggestions

[elad335]

Uh, there are thread safety issues and bugs with emulation stopping at this state.

[brian218]

Uh, there are thread safety issues and bugs with emulation stopping at this state. I'm also not sure why Emu.Restart() was choosed over Emu.Stop().

The watchdog is supposed to restart the game. Also, I've observed that some arcade games rely on the watchdog to make the game itself restarted, by stopping calling sys_game_watchdog_clear().
As for the thread safety, I adopted Emu.CallFromMainThread([](){Emu.Restart();}); so the Emu.Restart() will be called from the GUI thread, as if the player clicked "Restart" in the RPCS3 menu -> Emulation.

[elad335]

As for the emulation stopping bug, I was referring to the fact that the watchdog thread operation leaks even after GUI emulation stopping request is being issued, potentially restarting other applications in this time frame.

[brian218]

As for the emulation stopping bug, I was referring to the fact that the watchdog thread operation leaks even after GUI emulation stopping request ie veing issued, potentially restarting other applications in this time frame.

How about changing std::this_thread::sleep_for(1s); to a smaller value? or adding _sys_game_watchdog_stop() to the game shutdown process of RPCS3?
Also, the watchdog won't issue the restart request when Emu.IsStopped() == true.

[elad335]

Neither, it should be manged by a named_thread held by FXO and joined on emulation stopping implicitly by its destructor.

[elad335]

Also, the watchdog won't issue the restart request when Emu.IsStopped() == true.

This is also a race condition.

[brian218]

Neither, it should be manged by a named_thread held by FXO and joined on emulation stopping implicitly by its destructor.

Hmm. Maybe I can make another PR to optimize it later. Would you mind providing some examples of your suggestion?

[brian218]

If I understand correctly, you want the watchdog thread to be terminated/destroyed immediately right after the game is stopped, right?

[elad335]

Yes, and make the state of watchdog packed in a single atomic variable and updated atomically with fused error checking with its single atomic update.

[brian218]

Neither, it should be manged by a named_thread held by FXO and joined on emulation stopping implicitly by its destructor.

Hmm. Maybe I can make another PR to optimize it later. Would you mind providing some examples of your suggestion?

Any examples would be appreciated.