Да так и есть в его голове. Вот он мне что ответил:

This is almost certainly a known perl bug you are running into, and
there is nothing AnyEvent can do about it (the problem is not the
random/unpredictable order, the problem is that perl corrupts data
structures). I wrote a blog post about this if you are interested about
the details:

http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-or-how-perl-6-deals-with-bugs.html

In short, adding a check does not work, as you will have to check
basically EVERY access in your program, as you can never be sure whether
your code is called duriung global destruction or not. It is simpler,
easier and much faster to just do your cleanup as normal, and then call
_exit or some similar function.

Ссылку нужно прочитать, чтобы понять, что он так думает.

Насколько я помню - реальная смерть наступит при выходе из скоупа

Ну, судя по описанию, там где-то ещё ссылки внутри лупа лежат

А почему не при потере ссылки?)

Но я попробую сейчас в {} обернуть

Не помогает.

Сломан gd, а не Леман. Мы с UniEvent'ом у себя в итоге пришли к тому, что надо гарантировать отсутствие циклов, иначе нереально корректно завершаться.

gd?

Global destruction

Я так не хотел печатать это полностью)

Извините)

А, ну это понятно, там помимо циклов тоже могут быть проблемы, когда handle освободился в DESTROY, к примеру.

для pure-perl вроде ж gd ок, ну и когда "деструкторы тривиальны", т.е. нет прокрутки лупов и т.п.

Ну т.е. в частных кейсах ок, в общем - не ок)

Тогда не понятно.

А что не так с XS? Там вроде так же должны ссылки проверяться. Просто их много из-за событийной модели программирования.

нетривиальный кейс: объект a содержит b, b уже прибит gd, а a в деструкторе зовёт что-то на b. А теперь представь что b - объект на xs, и он уже был уничтожен. И получаем двойной вызов деструктора и обычно segfault

Нужно же проверять, что b не nullptr, не?

Не понял откуда второй вызов деструктора, если b уничтожен?

да, не 2-й вызов деструктора, а просто вызов метода на уже уничтоженном объекте

Ага, ну я это и написал, что приходится проверять все переменные. В pure perl с handler-ами так же

Понятно, что это проблема, особенно для событийного программирования, ну чо поделать, какой перл нам дали - такой есть. Собственно я Леману как-то так и ответил, что хватит в позе стоять, просто пойди if добавь.