Question Long lasting jobs? Unmanaged types without the Burst compiler?

According to https://docs.unity3d.com/Manual/JobSystemCreatingJobs.html

"When the job system picks up a job from its job queue, it runs the Execute method once on a single thread. Typically, the job system runs jobs on background threads, but it can choose the main thread if it becomes idle. For this reason, you should design your jobs to complete in under a frame."

I have a complex calculation that may take up to a second long. How would I deal with this?

Also, according to https://docs.unity3d.com/Manual/JobSystemNativeContainer.html

"The job system works best when you use it with the Burst compiler. Because Burst doesn’t support managed objects, you need to use unmanaged types to access the data in jobs."

What if I'm not using the Burst compiler? Do I still need to use unmanaged types?

 

If it's not guaranteed that it will never take more than 4 frames to complete you'd need to use Persistent or Domain allocator for the collections. Other than that, there is no issue here. Just check every frame whether the job completed.

Yes, because you will almost always be using a collection, and for thread safety reasons you need to use the native collections (com.unity.collections) which are struct types and they don't allow storing managed objects inside them.

Also, without Burst, you can jobify as much as you want but the speed gains will not be impressive. The same job with Burst disabled can run by a factor of 10 to 1000 slower - just a ballpark number but it's usually significant, and where it isn't the job's code probably wasn't really optimized with Burst in mind thus depriving Burst of many vectorization optimization opportunities.

 

On https://docs.unity3d.com/Packages/com.unity.burst@1.8/manual/building-projects.html it says "Projects that don't use Burst" "Xcode projects generated from the Create Xcode Project option" but through the command line it will only build the .app file. I have to build an XCode project from the command line for IOS, so I cannot use Burst.

It's fine if it still takes still takes 1 second, but I don't want to block the main thread for one second.

 

Also have slightly longer jobs and never encountered lags on main from that.
It is a bit concerning however that the docs state this could happen...

Don't know any built-in mechanism against that either.
What you can do, albeit with effort, is split your job into multiple smaller ones. Note that you can define dependencies via the handle on jobs to ensure they run in the exact desired order.