A lot of places call ThreadPool.QueueUserWorkItem() to offload tasks to a different thread, this is usually done to make sure tasks like model vertex calculations or texture loading don't block the network or render/update loop. However, this is being done in so many places that the threadpool gets a backbuffer of queued up items. Causing stuff like chunk updates, entity ticking etc not to be executed within a reasonable amount of time.
The Solution
First we should determine what tasks are currently being executed on the threadpool, we can then determine a fit solution for those items.
I imagine a lot of these can probably just be queued up to a BackgroundWorker instance. This will allocate 1 thread to process all of the queued items instead of taking up all of the threadpool threads.
The Issue
A lot of places call
ThreadPool.QueueUserWorkItem()to offload tasks to a different thread, this is usually done to make sure tasks like model vertex calculations or texture loading don't block the network or render/update loop. However, this is being done in so many places that the threadpool gets a backbuffer of queued up items. Causing stuff like chunk updates, entity ticking etc not to be executed within a reasonable amount of time.The Solution
First we should determine what tasks are currently being executed on the threadpool, we can then determine a fit solution for those items. I imagine a lot of these can probably just be queued up to a BackgroundWorker instance. This will allocate 1 thread to process all of the queued items instead of taking up all of the threadpool threads.
Any input on this problem is more than welcome!