PixarAnimationStudios
BUG: Compute extent with multi-threading may influence fetching material bindings
We found a very strange behavior that ComputeExtent along with GetForwardedTargets in a multi-threading way would influence the behavior of getting material binding with API UsdRelationship::GetForwardedTargets. See the changes of this PR about the test to reproduce this. In the test, it's trying to traverse the whole stage with multi-threads. All operations are supposed to be read-only to the stage, and the test should be successful. However, it fails unexpectedly sometimes. Adding TfRegistryManager::GetInstance().SubscribeTo<UsdGeomBoundable>(); to the first line of main() will pass the test, which we still have no idea why.
You need to run the test with --repeat until-fail:1000 to increase the possibility of failure.
On Linux, I had to use --repeat-until-fail 10000 to reproduce the failure.
Thanks for pointing this out and providing a test case. This one turned out to be a little tricky to hunt down, but the root cause ended up being the same for another mysteriously failing test we had been tracking on our side, a bonus win there.
In some cases, it is possible that a call to TfRegistryManager::SubscribeTo may return before all registry functions are called if there are multiple threads working registration functions off the worklist queue. In certain timing scenarios, this invalidated the assumption that all registrations were complete when Sdf_SpecTypeInfo::GetInstance returned. As a result, in certain timing scenarios, calling code that relied on this class to cast specs would see unexpected failures as valid casts would actually fail due to the Typeinfo singleton being in an incomplete state.
