Seeing jobs spawned by PhysicsSystem::Update execute after that function has returned

[miketuritzin]

A comment above PhysicsSystem::Update states:

This function internally spawns jobs using inJobSystem and waits for them to complete, so no jobs will be running when this function returns.

However, using JobSystemThreadPool, I'm seeing jobs continue to execute after PhysicsSystem::Update returns each frame. (I actually initially noticed this when trying to use enkiTS with an implementation of JobSystemWithBarrier, but now I'm observing it with the stock JobSystemThreadPool as well.)

I'm not adding any jobs to JobSystemThreadPool myself, so all jobs are added in PhysicsSystem::Update.

Is this expected? There is a lot of complexity in Jolt here, so I haven't dug in further yet, but I can try to if that's helpful.

[jrouwe]

The Job is considered 'complete' when the 'Execute' function has returned (or actually a few instructions before returning). JobSystemThreadPool however still needs to call Release to free the job before it can go to sleep. It is also possible that the main thread has stolen work in which case Execute will be called again on another thread. In this case the Job will do nothing because it is already in the 'done' state.

So yes, you can see that the threads are still doing some clean up work, but the actual work has been done when PhysicsSystem::Update completes.

If you see callstacks that actually call into PhysicsSystem::Job* after PhysicsSystem::Update finishes, then something is wrong and then I'd like to see what they are.

[miketuritzin]

Okay, thanks - this is very helpful! I added some more tracing/logging and I'm seeing the behavior you describe. Execute is called after PhysicsSystem::Update returns, but it's early exiting due to the job already being in the 'done' state. That's the big thing I missed earlier.