This fixes a problem noticed by @j9liu and @azrogers where Reinterop would leave a bunch of stale generated files lying around while renaming a class in Visual Studio. For example:
This happens because each time you press a key during the rename, Visual Studio starts a new compilation for Intellisense, without waiting for the previous one to finish. Each compilation runs Reinterop. There's apparently no (official? reliable?) way for Reinterop to detect that it's running inside Intellisense rather than a normal compilation. These multiple running copies of Reinterop race against each other to update the reinterop-inventory.txt file that keeps track of the .cpp and .h files that were generated, and so the contents of that file can get out of sync with the files that actually exist on the file system. When this happens, the next run of Reinterop won't know to clean up some of the files, and you end up with stale files lying around.
So my solution here is to wrap a giant named (system-global) semaphore around Reinterop so only one copy can run at a time, and any additional invocations will wait. Kind of terrible, but effective. I don't expect this will work anywhere but Windows due to lack of support for named, system-wide semaphores. But it should fail in such a way that just allows multiple copies of Reinterop to run, so it's no worse than before. There's also potential for an impact on Intellisense performance. It seems mostly ok to me, but let me know what you think.
As always with a Reinterop update, it's necessary to rebuild it (dotnet publish Reinterop~ -o .) and then restart Visual Studio for the new version to get picked up.
I'm sometimes seeing Unity completely hang while compiling our code, probably caused by the lock in Reinterop. Closing this until I can come up with a better solution.
This fixes a problem noticed by @j9liu and @azrogers where Reinterop would leave a bunch of stale generated files lying around while renaming a class in Visual Studio. For example:
This happens because each time you press a key during the rename, Visual Studio starts a new compilation for Intellisense, without waiting for the previous one to finish. Each compilation runs Reinterop. There's apparently no (official? reliable?) way for Reinterop to detect that it's running inside Intellisense rather than a normal compilation. These multiple running copies of Reinterop race against each other to update the
reinterop-inventory.txt
file that keeps track of the .cpp and .h files that were generated, and so the contents of that file can get out of sync with the files that actually exist on the file system. When this happens, the next run of Reinterop won't know to clean up some of the files, and you end up with stale files lying around.So my solution here is to wrap a giant named (system-global) semaphore around Reinterop so only one copy can run at a time, and any additional invocations will wait. Kind of terrible, but effective. I don't expect this will work anywhere but Windows due to lack of support for named, system-wide semaphores. But it should fail in such a way that just allows multiple copies of Reinterop to run, so it's no worse than before. There's also potential for an impact on Intellisense performance. It seems mostly ok to me, but let me know what you think.
As always with a Reinterop update, it's necessary to rebuild it (
dotnet publish Reinterop~ -o .
) and then restart Visual Studio for the new version to get picked up.