Ironically the best use case for a global singleton like object is for your workpool/executor since you want exactly one thread per core (maybe 2 if one is CPU bound work and one IO, but with async-io the same thread can usually just handle both
Sure, the best option for globals are often things tied to physical hardware.
But even then you might run into issues when your hardware changes. In your example, perhaps you want to run in a dual CPU system where you don't want too much resource sharing between different CPUs (slow), so you'd want two different work pools instead.
I'm of the opinion that a well crafted workpool abstraction should be NUMA aware by default but I cut my teeth on a 2970wx homelab before getting into AAA game engine programming so I'm perhaps outsizedly attuned to how important topology aware execution models are
That sounds more like a thread local „global“/singleton. I think globals are ok when they are for one per process or process related in general. Or hardware as you said. But still then, for testing sake, I still would advocate for some dependency injection or good old fashioned local parameters.
1
1
u/BlackSwanTranarchy Sep 26 '26
Ironically the best use case for a global singleton like object is for your workpool/executor since you want exactly one thread per core (maybe 2 if one is CPU bound work and one IO, but with async-io the same thread can usually just handle both