Предотвратит ли перемещение управляемого объекта в памяти использование GetComInterfaceForObject и передача возвращенного IntPtr неуправляемому коду? Или clr каким-то образом поддерживает этот ptr? Обратите внимание, что неуправляемый код будет использовать это на протяжении всего жизненного цикла программы, и мне нужно убедиться, что управляемый объект не перемещается сборщиком мусора. (По крайней мере, я думаю, что это правильно?)
- РЕДАКТИРОВАТЬ - Хорошо, я нашел некоторую информацию, и я думаю, что это может быть ответом. Он имеет дело с делегатами, но я должен был бы поверить, что вызов GetComInterfaceForObject делает что-то в том же духе.
«Управляемые делегаты можно маршалировать в неуправляемый код, где они отображаются как указатели на неуправляемые функции. Вызовы этих указателей будут выполнять переход от неуправляемого к управляемому, изменение соглашения о вызовах, вход в правильный домен приложения и любое необходимое маршалирование аргументов. указатель на неуправляемую функцию должен ссылаться на фиксированный адрес. Было бы катастрофой, если бы GC перемещал его! Это приводит к тому, что многие приложения создают дескриптор закрепления для делегата. Это совершенно не нужно. Указатель неуправляемой функции на самом деле ссылается на собственный заглушка кода, которую мы динамически генерируем для выполнения перехода и маршалинга. Эта заглушка существует в фиксированной памяти за пределами кучи GC.
Однако приложение отвечает за то, чтобы каким-то образом продлить время жизни делегата до тех пор, пока не прекратятся вызовы из неуправляемого кода. Время жизни заглушки собственного кода напрямую связано со временем жизни делегата. После сбора делегата последующие вызовы через указатель неуправляемой функции приведут к сбою или иному повреждению процесса. В нашем недавнем выпуске мы добавили пробу отладки клиента, которая позволяет вам четко обнаруживать эту слишком распространенную ошибку в вашем коде. Если вы еще не начали использовать Customer Debug Probes во время разработки, взгляните!»
