Регистрация | Войти
Lisp — программируемый язык программирования
RSS
FFI: деаллокация и классы
shamaz.mazum - 15.03.2018 14:43, Сообщений - 11
Привет. А что, если я хочу деаллоцировать некий объект из сишной библиотеки, когда GC удаляет объект из CLOS? Мне нужно что-то вроде make-instance или initialize-instance, только для деинициализации, как деструктор из цпп. Что можно использовать? 
[#]
Привет. Я нашел вот это - http://comp.lang.lisp.narkive.com/pmyqISQv/destructors-in-lisp.
Hedin - 15.03.2018 15:05
[#]
Вот еще - http://lisper.ru/forum/thread/784
Hedin - 15.03.2018 15:13
[#] Ответ на комментарий от Hedin 15.03.2018 15:05
Ага, спасибо. Я тоже на это наткнулся, когда гуглил. Толком не дочитал до конца, оказывается проблема ещё хуже, чем я думал. Хотя можно всегда засунуть регистрацию финализатора в initialize-instance.

Хочу обертку OpenCL для лиспа. Всё, что нагугливается мертво и без документации.
shamaz.mazum - 15.03.2018 16:57
[#]
Не делай так. 
den73 - 15.03.2018 21:50
[#] Ответ на комментарий от den73 15.03.2018 21:50
В смысле?
shamaz.mazum - 16.03.2018 08:52
[#] Ответ на комментарий от shamaz.mazum 16.03.2018 08:52
Финализатор вызывается в неизвестный момент, и нет гарантии, что вообще когда-то вызовется. Ты уже теряешь контроль над освобождением ресурсов, сидящих в объектах С++. Далее, любая ошибка в деструкторе приведёт к плавающим сегфолтам твоей программы. Наконец, порядок вызова финализаторов не определён. Поэтому если у тебя важен порядок деструкторов, то ты попал. Если тебе нужно убивать объекты С++ из лиспа, заведи метод close и какое-нибудь with-ensured-close-call (наподобие with-open-stream). Метод close твоего лиспового объекта будет явно убивать объект С++ и помечать лисповый объект как трупик. И работай так, как ты работал бы в плюсах. Финализатор тоже оставь. Он должен всего лишь проверять, что close для данного объекта уже выполнен. И если не выполнен, изрыгать страшные проклятия. 

И помни, что финализаторы тоже стоят денег. Недавно в SBCL был патч на эту тему и они стали несколько быстрее. А раньше вообще было какое-то быстрое замедление времени сборки из-за слабых ссылок. Если у тебя много объектов, то это будет беда. Хотя я говорю про слабые ссылки, но вроде это примерно одно и то же и должно обрабатываться в единой среде. 
den73 - 16.03.2018 09:05
[#] Ответ на комментарий от den73 16.03.2018 09:05
den73, полностью поддерживаю.
shamaz.mazum, если сделать освобождение ресурсов в финализаторе, будет весело выгребать баги, которые происходят в случайные моменты времени и без всякого стэк-трейса (в этом пункте не уверен, надо будет проверить). Это из опыта работы в C#, происходит exception в деструкторе и приложение закрывается без всяких сообщений. Не знаю как сейчас, но лет 5 назад выловить где происходит исключение, была та еще задачка.
Hedin - 16.03.2018 09:45
[#] Ответ на комментарий от den73 16.03.2018 09:05
Финализатор вызывается в неизвестный момент, и нет гарантии, что вообще когда-то вызовется. 

Не важно.

Наконец, порядок вызова финализаторов не определён.

В моём частном случае тоже не важно, я думаю.

with-ensured-close-call

Вот это убого просто. Ни сохранить созданный таким образом объект в каком-нибудь списке, не замкнуться на него.

Так-то ты прав, но когда пофиг, в каком порядке вызывать, лучше финализировать, я думаю
shamaz.mazum - 16.03.2018 11:16
[#] Ответ на комментарий от Hedin 16.03.2018 09:45
А что, тот же sbcl не ловит чужие сегфолты? ЕМНИП, ловит
shamaz.mazum - 16.03.2018 11:17
[#] Ответ на комментарий от shamaz.mazum 16.03.2018 11:16
Вот это убого просто. Ни сохранить созданный таким образом объект в каком-нибудь списке, не замкнуться на него.
Это не убого, а частное решение для тех случаев, когда тебе надо, чтобы объект закрылся при выходе из текущей области действия, невзирая на нелокальные возвраты. Сохранить ты его можешь и в этом случае, но оно может внезапно для пользователя умереть.  

Ну, выбор за тобой в любом случае. 
den73 - 16.03.2018 14:57
[#] Ответ на комментарий от shamaz.mazum 16.03.2018 11:17
Тебе сложно будет связать сегфолт, который произошёл через 100 лет после повреждения объекта, с причиной, вызвавшей повреждение оного. Если объекты удаляются детерминированно, то это гораздо проще. 
den73 - 16.03.2018 14:58
@2009-2013 lisper.ru