There are 3 different ways the user can trigger quitting an application.
MCP_PowerButtonControl(1) returned 0message is displayed.
The Wii U system software makes all these paths appear the same to the application so that the application can perform identical exit processing.
If currently in foreground mode, to skip the transition to background (BG) mode before exiting, use
OSEnableForegroundExit for applications that can tolerate multiple exit paths.
If the game has inflight file system (FS) and network (NET) APIs running on cores 0 and 1 or if the user triggers a game shutdown, the game shutdown sequence must provide the following correct sequence of events:
The basic process for shutdown:
This is the same process as switching user interface to HBM via an
OS_SYSTEM_MESSAGE_DATA0_RELEASE_FOREGROUND message from the System Message Queue. The application releases all of the User Interface Devices when switching to BG mode. The system automatically triggers a transition to BG mode if it is required for shutdown. If process exit is requested at HBM, the application is already in BG mode.
The application must wait for the
OS_SYSTEM_MESSAGE_DATA0_EXIT message from the System Message Queue prior to proceeding with exit processing. The COS provides CPU cycles for all 3 cores during exit processing.
Ideally, the application can pause/close all threads except the thread performing exit processing. This prevents possible state collision between threads and exit processing. Although it is not absolutely necessary to pause/close all threads, the system exit handler waits for all CPUs to go idle before shutting down drivers. Threads that do not yield may cause the system shutdown to stall. If there are many threads left running during exit processing, there are increased chances for state collision.
An example of a collision is C++ static global objects. If threads are left running using these objects, calling the
exit function will trigger C++ static global destructors and likely cause the program to crash.
Alarms are considered temporal threads. Applications should attempt to cancel all alarms.
There are three ways that you may exit your application:
Returning from the
main and calling
exit call the destructors of C++ static objects. The order in which the destructors of static objects are called is undefined. If you are not careful with your implementation, objects with inter-dependencies may hang.
It is difficult to resolve this issue cleanly if you code the exit processing for your application late in the development cycle. In this case, you may use the
_Exit function to exit the application without calling the destructors of C++ static objects.
_Exitare called, any thread left running by the application must NOT:
To make it easier to develop application shutdowns, the 2
exit functions may be called from any core and from inside RPX or RPL.
The diagram below shows the process states for a simple shutdown:
RELEASE_FOREGROUNDis retrieved from the system message queue
OSReleaseForegroundis called from all three cores
ACQUIRED_FOREGROUNDis retrieved from the system message queue
EXITis retrieved from the system message queue
2015/03/19 Formatted as 'IMPORTANT' note.
2014/07/17 Remove step 3 (stop or cancel all I/O and close all files); no longer necessary. Add warning to step 4 about synchronous FS calls.
2013/05/08 Automated cleanup pass.