We don’t have access to the JobHandle source, so a few questions about this:
Is there any downside to prioritizing the jobs in this way? For example: if the job scheduler was already ordering these jobs in an optimal way, would I now be telling it to reorder them in a suboptimal way? Can this reordering of job priorities have any affect on performance?
If the jobs can’t be executed on the calling thread (for example, they’re already started on other threads), what does the calling thread do? Is it guaranteed to do nothing (but check the status of the job handle) until the handle jobs are complete?
I’ll try my best to answer your questions, but someone else will probably answer it better
I read somewhere else that jobs aren’t really “scheduled” until JobHandle.ScheduleBatchedJobs() is called. Calling this method moves jobs from a local queue to the global queue where they are sorted. However, there is overhead to calling it, so only do so after a large number of jobs is scheduled. On a side note, a JobComponentSystem automatically calls JobHandle.ScheduledBatchedJobs() after exiting from Update. In the end, it is best to call JobHandle.Complete only when absolutely necessary, since if any of that job and its dependencies have yet to finish, the main thread will block.
The calling thread will block until that thread is done. This is seen as a grey bar labeled “Semaphore.WaitSignal” in the Profiler. You never want this unless the main thread has finished scheduling all the jobs within a frame, and is waiting for them all to finish. This is the ideal case.