After a bit of investigation, I have determined that it is not safe to implement Clone for RenderDoc under any circumstances. Allowing the entry point to be cloned is technically unsound because it can result in the following behavior:
Clone existing RenderDoc instance foo into another variable binding bar.
Send bar to a separate thread.
bar.shutdown() is called early in the process to shut down the API, consuming self and preventing bar from being used further.
However, the foo instance still exists. Calling any API methods (marked safe or unsafe) on it is undefined behavior.
Even so, while the shutdown() method is indeed prominently marked unsafe, there are other issues as well. The trigger capture and trigger multi-frame capture function calls are unsound if cloning the entry point is permitted because their corresponding stop and start methods could result in unpredictable behavior if called on multiple threads by separate RenderDoc instances on the same window and device handle pair.
Despite being a breaking API change, removing the Clone implementation is critical to statically preventing the memory and thread safety pitfalls described above. This should be documented clearly in the CHANGELOG.md so users looking to upgrade may be aware of the change.
After a bit of investigation, I have determined that it is not safe to implement
CloneforRenderDocunder any circumstances. Allowing the entry point to be cloned is technically unsound because it can result in the following behavior:RenderDocinstancefoointo another variable bindingbar.barto a separate thread.bar.shutdown()is called early in the process to shut down the API, consumingselfand preventingbarfrom being used further.fooinstance still exists. Calling any API methods (marked safe or unsafe) on it is undefined behavior.Even so, while the
shutdown()method is indeed prominently markedunsafe, there are other issues as well. The trigger capture and trigger multi-frame capture function calls are unsound if cloning the entry point is permitted because their corresponding stop and start methods could result in unpredictable behavior if called on multiple threads by separateRenderDocinstances on the same window and device handle pair.Despite being a breaking API change, removing the
Cloneimplementation is critical to statically preventing the memory and thread safety pitfalls described above. This should be documented clearly in theCHANGELOG.mdso users looking to upgrade may be aware of the change.