Processor scheduling

Group cpu · 5 exports · from forks/gamexueren/scripthook.h (framework 1.0-beta7-wildm1, SH_API_VERSION 2)

The processor set and the process priority the framework holds for each stage of the game's start up, the efficiency mode, and the read-only queries a plugin can use to see them.

Why a plugin would want to: while a dial is in force the framework answers the whole process for the processor count, the topology, the affinity and the priority. That is what keeps the engine from spreading itself back over every core, and it means GetSystemInfo and friends report the trimmed set to every caller, a plugin's included - a thread pool sized from them is sized for the set that is really allowed, which is usually what a caller wants, but it is no longer the machine's own answer. These calls say what the framework is doing instead. With every dial left alone nothing is hooked and every answer is the machine's own; the queries below still work and report that truthfully.

Export	Summary
ShCpuGetStatus	Fill *out with the launch's scheduling result.
ShCpuStage	The stage the framework is in now (SH_STAGE_*), cheap and safe to poll.
ShCpuAllowedMask	The processors the process may run on while a dial is in force, or 0 when nothing trims the set.
ShCpuReportedCount	How many processors the engine is told the machine has (0 = as-is).
ShCpuOnStageChange	Be told when the stage changes: called once per change with the new SH_STAGE_*, never with the stage already in force - at most twice in a session, since the stages only move forwards.

ShCpuGetStatus

SH_API int      ShCpuGetStatus(ShCpuStatus *out);

Fill *out with the launch's scheduling result. 0 only for a NULL argument: the dials are read on the attach path, so there is always something to say.

scripthook.h, line 2396

ShCpuStage

SH_API int      ShCpuStage(void);

The stage the framework is in now (SH_STAGE_*), cheap and safe to poll. True whether or not any dial is set, and it only ever moves forwards, so a caller can latch on the first SH_STAGE_PLAY and stay latched. This is the framework's own reading of the start up and not a second game state: the engine's states put the main menu and every lobby in one bucket and do not tell the logo window from the game's own, and those two are exactly the boundaries drawn here.

scripthook.h, line 2405

ShCpuAllowedMask

SH_API uint64_t ShCpuAllowedMask(void);

The processors the process may run on while a dial is in force, or 0 when nothing trims the set. This is the mask the affinity hooks answer with, so a caller can place its own work inside it on purpose.

scripthook.h, line 2410

ShCpuReportedCount

SH_API unsigned ShCpuReportedCount(void);

How many processors the engine is told the machine has (0 = as-is). The number the count hooks report: lower than the machine's own while a dial trims the set.

scripthook.h, line 2415

ShCpuOnStageChange

SH_API int      ShCpuOnStageChange(ShCpuStageFn fn, void *user);

Be told when the stage changes: called once per change with the new SH_STAGE_*, never with the stage already in force - at most twice in a session, since the stages only move forwards. One slot per plugin (the caller's module is the identity, as with ShPluginOnBlocked) and eight plugins can subscribe; calling in with NULL clears this plugin's slot. 1 when accepted, 0 with ShLastError saying why. The callback runs on the framework's stage thread and may call back into the framework.

scripthook.h, line 2424