Time-sensitive threads
Games want to get as much performance as they possibly can from the system. To support this, some of the game's threads are time-sensitive in that they don't want any unexpectedly long-running operations to take place on those threads. A canonical example of a time-sensitive thread is the one used for the game's rendering.
The Gaming Runtime Services (GRTS) makes it a little bit easier to identify what APIs aren't safe to call on a time-sensitive thread.
Note
You can identify GRTS APIs because they begin with "X" (for example, XGameSaveInitializeProvider or XGameGetXboxTitleId).
For the identification system to work, games need to call XThreadSetTimeSensitive on their time-sensitive threads. This API stores a bit in thread local storage that can be queried by GRTS APIs.
A GRTS API that's considered safe to call on a time-sensitive thread will exhibit a consistent runtime performance when given the same input. If a GRTS API isn't safe to call on a time-sensitive thread, the GRTS API has an internal call to XThreadAssertNotTimeSensitive. If the unsafe function is called on a thread that has been marked as time-sensitive, the following happens.
- If a debugger is attached, an assert gets triggered and the developer is informed of the violation. Developers also get instructed on how they can then globally disable the breakpoints.
- An Event Tracing for Windows (ETW) event is emitted that can be viewed in XbWatson (NDA topic)Authorization required.
Unsafe functions for time-sensitive threads
The following GRTS API functions aren't safe to call on time-sensitive threads. All other GRTS API functions are time-sensitive–safe and can be called on time-sensitive threads.