Re[9]: ReaderWriterLockSlim problems
От: Sinix  
Дата: 10.01.14 10:27
Оценка: 21 (1)
Здравствуйте, scale_tone, Вы писали:

S>>Безопасно, если соблюдать ряд простых правил:

S>>1. Unmanaged-ресурсы аллоцируются и освобождаются через наследника от SafeHandle.

_>А если нет? Что если TrickyMethod, скажем, видео конвертирует, с применением ассемблерных вставок? Что, выгрузка домена в сочетании с Thread.Abort() могут как-то покораптить основной домен?

Аппдомены не изолируют нативный код. Если с ним проблемы, то нет никаких гарантий, что он не покорёжил память процесса в целом. Если с ним нет проблем — нужно следить, чтобы все unmanaged-ресурсы (в том числе аллоцированные области памяти) освобождались при выгрузке домена. Если не рассматривать извраты с CER, остаются только SafeHandle (или другие наследники от CriticalFinalizerObject).

_>Конкретно, разница в том, что в SafeCaller.CallSafely() поток запускался внутри временного домена, а тут, в SafeCaller.CallNotSoSafely() поток запускается (и абортится) в основном.

_>Будет разница в безопасности?

В принципе — разницы быть не должно. Пара оговорок:
1. Я с аппдоменами плотно работал лет 5-6 назад, так что могу и ошибаться
2. Thread.Abort() не гарантирует немедленного завершения потока (он может вообще не завершиться, см ResetAbort()). Как минимум Join() нужен.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.