public interface IWorkerPlacementWhere a worker thread should run, asked of the worker itself as it starts.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
The seam exists because affinity is a property of the calling thread. Every per-OS primitive behind this — SetThreadGroupAffinity, sched_setaffinity(0, …) — pins whoever calls it. So the placement cannot be applied by the thread that constructs the scheduler, and a design that computed a table up front and applied it from there would pin the constructing thread WorkerCount times and leave every worker exactly where it was, with no counter anywhere reading differently. TryPlace is therefore called on the worker, before its first take.
And because this assembly may not know what a processor is. The topology lives in Vixen.Platform, which is above this one; an interface here, implemented up there, is the same dependency the other way round — the shape JobAccess already uses for resource ids and IRemoteLogTransport for the inspector protocol.
⚠ Pinning is not free and is not a default. A pinned worker cannot be moved off a core the OS has given to something else, so on a machine running anything besides the game it is a pessimisation rather than an optimisation — which is why JobScheduler has no placement unless a caller supplies one, and why TryPlace returning is an ordinary answer rather than a failure. macOS gives quality-of-service classes instead of affinity masks and answers everywhere.
Methods (2)
bool TryPlace(int ordinal, int workerCount)Places the calling worker thread, which is the one being started.
void Release()Undoes TryPlace for the calling worker thread.
Used by (4)
- JobSchedulerVixen.Core.Threading
- ProcessorAffinityPlacementVixen.App.Hosting
- RecordingPlacementVixen.Core.Threading.Tests
- ThrowingPlacementVixen.Core.Threading.Tests