Вопрос такой же, как в заголовке, и ниже приводится предыстория:
На Linux я пытаюсь использовать dlopen () et c для создания инфраструктуры плагинов C ++ .so, которая имеет минималистичный и чистый интерфейс. Это означает:
- Загрузка плагина и создание одноэлементного объекта (C ++) из плагина просто включает в себя вызов функции
makePluginObject()
с путем к загружаемому файлу .so и возвращением указателя на предмет. Под капотом эта функция вызывает dlopen (), за которым следует фактическое размещение и построение объекта. Объект относится к классу C ++, реализация которого находится в .so. - Позже пользователь может просто удалить (вызывая dtor) указатель, чтобы выполнить всю необходимую очистку, включая dlclose (), что выполняется с помощью доктор. Это будет реализовано путем вызова dlclose () в dtor объекта. (Под капотом дескриптор из dlopen () был передан объекту во время
makePluginObject()
.) Важно отметить, что пользователь не может явно вызвать дополнительную функцию отключения / отключения.
Выше design, вероятно, означает, что код, вызывающий dlclose (), находится в расширяемом .so. Ключевой вопрос таков: нормально ли код вызывать dlclose () сам по себе? Мне интересно, потому что наивная реализация dlclose () отключает отображение из памяти кода, который все еще выполняется во время уничтожения объекта.
Важно, чтобы пользовательский интерфейс оставался таким простым. Пользователю просто нужно вызвать makePluginObject()
и удалить полученный указатель, когда он закончит. Если введена функция разрыва, которую пользователь должен явно вызвать после удаления объекта, тогда интерфейс будет намного тяжелее, и нагрузка на пользователя будет намного больше. Я знаю, что делать, если разрешена явная функция разрыва, и этот вопрос не об этом варианте использования.
В моих экспериментах сбоев не было, но казалось, что dlclose () на самом деле не работает что угодно, потому что valgrind сообщил о большом количестве доступной памяти, связанной с моим вызовом dlopen ().