SB
Size: a a a
2021 February 11
IC
ты в него this аргументом передаешь
и это должно помочь от конкурентного вызова с финализатором из за того, что руты сохранятся?
I
Тогда получается что такой кейс с рейсом с финализатором происходит только из-за того, что условный челик не соблюдает паттерн, которому уже туева хуча лет?
I
Это обсуждается уже часа 3, забавно, если итог таков.
DP
Так а что толку от супресса в конце
DP
Конкурентность то будет всерно
DP
Ты же супресс делаешь уже после утилизации ресурсов
DP
Вот и финалайзер и диспоз вместе заедут в утилизацию
I
Конкурентность то будет всерно
Конкурентность разных потоков при вызове диспоуза или конкурентность основного и финализирующего потоков?
I
Тот паттерн больше против двойного вызова логики удаления. А то что может быть конкаррент - это хитрожопый кей с джитом
Ну, паттерн с supress finalize студия так же из коробки предлагает реализовать
DP
Конкурентность разных потоков при вызове диспоуза или конкурентность основного и финализирующего потоков?
Основной и финалайзер. Конкурентность разных потоков надеюсь не пишут программисты. А от второе от них не зависит
I
Тогда не понимаю как может файналайзер запуститься, если у тебя SuppressFinalize ещё не вызван, а джит знает что this ещё будет нужен для вызова этого метода
I
Он этот метод не уберёт никуда
I
и this останется висеть на стеке как рут
DP
Переслано от Anatoly
очень просто, запустился Dispose(), выполняется, пользователь/оркестратор прибил аппу и финалайзер срочно-решительно побежал по финалайзер queue.
более того, если диспоз уже вызван и вы в нём не работаете с полями объекта, он может не считаться рутом для ГЦ и его можно собрать
более того, если диспоз уже вызван и вы в нём не работаете с полями объекта, он может не считаться рутом для ГЦ и его можно собрать
I
Или в регистре, не важно
I
Ну и?) У тебя в dispose какая-то операция и потом SuppressFinalize (this)
I
Пока твоя операция не выполнится, this будет жить