Rate limit engine systems w/ ScheduledExecutorService instead of DIY rateLimit method

[ultraq]

I made use of ScheduledExecutorService the other day to rate limit the update of memory usage / GC collection stats in the debug overlay, and I'm wondering if it's a better way to perform the rate limiting I have in some engine systems so I don't have to have a custom rateLimit method.

In DebugOverlay:

redhorizon/redhorizon-engine/source/nz/net/ultraq/redhorizon/engine/graphics/imgui/DebugOverlay.groovy

Lines 81 to 84 in 8f4bd81

	Executors.newScheduledThreadPool(1).scheduleAtFixedRate({ ->
	memoryUsage = ((runtime.totalMemory() - runtime.freeMemory()) / 1024) / 1024
	garbageCollections = ManagementFactory.garbageCollectorMXBeans.inject(0L) { acc, bean -> acc + bean.collectionCount }
	}, 1, 1, TimeUnit.SECONDS)

And if I'm leaning more on executor services for the engines, then I wonder if it'd be good to rewrite them so that their run methods are only for the loop executions to be passed to such executors. This'll mean having to extract all the setup/teardown logic around the loops and into their own methods, but doing that might lead to smaller methods since I don't have to mix it all in one.

• Make EngineSystem have a setup method to do just that, returning some "context" object of the created objects to pass around
• Make the run method accept the context object so it has access to those resources
• Make the teardown also accept the context object to release resources, or can we make the context implement Closeable to do it automatically? Note that there might be some threading issues here, especially in the graphics system, where operations can only be performed by the current graphics thread

[ultraq]

Haven't done the scheduled executor thing, but I swapped out the complicated engine system startup/shutdown with Java 21's thread builder, and it's made that area far more bearable. I think I'd still rather each system owned their own threads as it definitely makes the context management less messy (no having to constantly do context.withCurrent { ... } blocks for each potential thread), though I'd still like to give it a shot, especially for the systems where this isn't such an issue (ie: anything that isn't the OpenAL/OpenGL contexts). So I'll keep this issue open for a while to remind myself of it and revisit when I want.

[ultraq]

Ah, one issue with this: you can't evaluate the Thread.interrupted() condition from within the runnable passed to ScheduledExecutorService because then it'll be that scheduled thread's state and not the one from the engine system 🤔