Closed Chocohead closed 4 years ago
using the same executor service won't work in the event a mod decides to wait on an async task for whatever reason. I should have used a lock, and for some reason didn't. I think rrp is in need a big upgrade though, since modders can't choose the priority of the resource pack, along with the inefficiencies of using String#format for templating, and then creating a byte array from that
I've rewritten the whole thing from scratch, will commit soon:tm: once wiki is done, I think the threading is much better this time
Well there you go, all done I think
I'm in the situation where I have potentially a significant number of runtime assets which are relatively slow to read which all need giving to RRP. With the way this is designed I would've thought the
rrp_pre
entrypoint would work, yet its implementation is just a serial loop in another thread. Whilst there is nothing wrong with this, it leaves me with a choice of three scenarios:rrp_pre
entrypoint and block the thread until the initial reading (which is still on thread from a differentpreLaunch
entrypoint) is done, then add the resources.preLaunch
entrypoint and add things asynchronously in my own threadRRPPre.PRE_GEN_LOCK
can do that). Potentially this is not important as the resources may not be accessed until later, but I cannot guarantee this for them all nor have a way of knowing for a given resource if this is the case.RuntimeResourcePack
should probably warn of it given they are not backed by thread safe collections. It's all quite innocent inRRPPreGenEntrypoint
which suggests they are all safe enough to call which could make for some strange CMEs from the main thread.preLaunch
entrypoint and add things synchronouslyI have a feeling everything isn't designed with threading in mind (which is totally fine. it can be a pain to design for), but if speed is the goal to use this over Artifice it shouldn't be left taped on IMO. I have given it a little thought about possible solutions at least if you'd like some ideas:
RuntimeResourcePack#EXECUTOR_SERVICE
)ReloadableResourceManagerImplMixin#registerRDP
which is a bit naughty.EntrypointUtils
and instead parallelise theList
returned byFabricLoader#getEntrypoints
.Future
s and allow mods to chain their resources into the loading processPhaser
and then use that as a form of self asserted thread pooling.Phaser
s tostunterminate if they're being slow/you want them to with a single method call.There's probably an argument for an entirely threaded form of
RuntimeResourcePack
, maybe even usingSemaphores
to limit concurrent writes or just as a lazy way of de-threading calls (or aReentrantReadWriteLock
which would work for that task too), but maybe there's a point of diminishing returns eventually where it doesn't quite need to be that complicated. All food for thought in making the generation faster at least.