Wish I had an answer… But figured I’d at least chip in that I’m running into a similar problem in another thread about NavMesh …
It seems absolutely crazy to me that the Unity rendering system uses jobs internally, yet it can’t prioritize itself over other jobs… And in my case, Unity’s own internal NavMesh jobs can overrun the rendering jobs if submitted enough data… If they’re not going to bother implementing prioritization, why doesn’t rendering at least have its own queue or worker pool or something?
It feels like some of the Jobs philosophy is just missing the mark here - it’s pitched as a way to multithread code, make better use of CPU cores, huge performance gains with burst, and not be limited to the main thread, with the logical conclusion that you’d want to use it for large amounts of work… Except that so much of the system is designed around short bursts of work, which make it clunky for 80% of the types of things you’d want it for. Stuff that runs for long periods of time and/or across many workers actually causes frame freezes which is probably what you were trying to get around in the first place…
I appreciate Unity pushing into multithreading, async work, the burst compiler, etc, but so many of the APIs just totally miss the mark and I end up having to shelve them and do things an entirely different way because these only get 90% of the way there.
Case in point, the NavMesh.UpdateNavMeshDataAsync() you would think be helpful in building NavMesh data in the background… Except that you have to submit the data on the main thread, you have to read the result on the main thread, and submitting too much data freezes the main thread when the renderer needs the job system. Why do I have to jump through hoops putting my inputs together, scheduling them back to main, and then schedule other repeating work to check for completion on main, only to find a brick wall of locking the main thread in circumstances I can’t measure or predict?
The jobs system is 5 years old and still this is unaddressed?