LINUX.ORG.RU

Как работает dlopen?


0

3

Пишу прогу, требуется поддержка плагинов.

Вопрос следующего характера - на сколько тяжёл вызов dlopen? Думаю сделать кэш этих самых плагинов. Встал вопрос где хранить инфу о плагине - написать её в текстовом файле и хранить в зипе вместе с библиотекой плагина, или вкомпилить эту самую инфу в библиотеку и каждый раз подгружать библиотеку, добавлять инфу в кэш, после чего выгружать и загружать позже по надобности.


Вопрос следующего характера - на сколько тяжёл вызов dlopen?

Для плагинов все равно ничего легче нет (ну разве что скрипты, но вряд ли это легче).

Думаю сделать кэш этих самых плагинов.

???

Встал вопрос где хранить инфу о плагине - написать её в текстовом файле и хранить в зипе вместе с библиотекой плагина, или вкомпилить эту самую инфу в библиотеку и каждый раз подгружать библиотеку, добавлять инфу в кэш, после чего выгружать и загружать позже по надобности.

Правильный способ - вкомпиливать.

Deleted
()

На одно из серваков писалось так: при входящем сообщении вызывалась функция, которая искала в односвязном списке библиотеку, способную обработать сообщение. В каждом элементе списка содержится 2 поля: идентификатор типа сообщения, путь в dll/so. При нахождении подходящей либы сообщение обрабатывалось при помощи функции, вызванной из этой либы. Соответствие типа сообщения и имени dll/so задается в INI-файле.

Dikar ★★
()
Ответ на: комментарий от Dikar

Видимо на столько Ъ что только загоровки читаешь.

Суть вопроса не в том как им пользоваться. Как пользоваться я разобрался. Мне интересно внутреннее устройство функции, а в исходники лезть не хочется. Оно полностью загружает библиотеку в память? Или что оно делает? Просто возможны плагины весом мегабайт в 10-20, а я хочу понять на сколько удачная идея подгружать и выгружать библиотеки для создания кэша.

com
() автор топика
Ответ на: комментарий от Deleted

???

В указанном каталоге лежит N плагинов. Нужно вычислить что из них плагин и кто он такой. Далее (грубо говоря) спросить у пользователя хочет ли он грузить 5 вот этих плагинов и не грузить 5 вот этих.

com
() автор топика
Ответ на: комментарий от com

Если нужна такая фича, то рациональнее будет хранить информацию о плагине отдельно от самого плагина.

Deleted
()
Ответ на: комментарий от com

Оно полностью загружает библиотеку в память?

Да.

Deleted
()
Ответ на: комментарий от com

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

Если я правильно понял идею, и плагинов много, и среди них есть большие, то таки отдельно хранить инфу.

Deleted
()
Ответ на: комментарий от Deleted

Угу. Вот отсюда вопрос и назрел. Теперь остаётся непонятным что быстрее - раззиповать архив с этим самым плагином и прочитать оттуда инфу (а эта самая раззиповка тоже требует ресурсов и времени), или всё-таки вкомпилить инфу в библиотеку и вызывать dlopen а затем dlclose.

com
() автор топика
Ответ на: комментарий от com

Теперь остаётся непонятным что быстрее - раззиповать архив с этим самым плагином и прочитать оттуда инфу (а эта самая раззиповка тоже требует ресурсов и времени), или всё-таки вкомпилить инфу в библиотеку и вызывать dlopen а затем dlclose.

man zip. Чтобы достать из него файл, нужно раззиповать только этот самый файл. И zip может работать без компрессии. И тебе ведь нужно инсталлировать плагины, поэтому раззиповка самого плагина (.so) - однократная операция, только при установке.

Deleted
()
Ответ на: комментарий от com

думаю раззипока больше ресурсов отожрёт т.к. её надо будет каждый раз проводить.

Короче, кэширование твой выбор. Только нужен механизм поддержки кэша в актуальном состоянии во избежание.

true_admin ★★★★★
()

имхо лучше всего при старте программы загрузить ВСЕ плагины в память.

при инициализации плагина он, разумеется, даёт основной программе всю информацию о себе.

KivApple ★★★★★
()
Ответ на: комментарий от akk

Чтобы можно было распрстранять в виде «1 файл - 1 плагин».

Deleted
()

на сколько тяжёл вызов dlopen? Думаю сделать кэш этих самых плагинов.

Не пишите больше ничего.

r2d2
()
Ответ на: комментарий от com

Если я правильно понял, то можно посмотреть реализацию в libpurple (той самой, на которой Pidgin работает). Она сохраняет список загруженных плагинов в файл, и при повторном выполнении программы можно вызвать функцию purple_plugins_load_saved(), которая загружает все плагины, которые были в загруженном состоянии при выходе из программы.

hippi90 ★★★★★
()

По-моему у топикстартера ПРЕЖДЕВРЕМЕННАЯ ОПТИМИЗАЦИЯ.

stack_protector
()

на сколько тяжёл вызов dlopen

man dlopen -> RTLD_LAZY

Как бы сделал я:

1) Если писать на скорую руку - вкомпиливать
2) Если писать нормально:

2.1) Самый хороший вариант, распространять плагины в составе deb/rpm/etc. Плагин - каталог в /usr/lib/...

2.2) Если нужен обособленный проприетарный софт, то тогда zip, внутри конфиг.
Наверняка потом понадобятся еще файлы, например .so для разных архитектур.

user_2190
()
Ответ на: комментарий от Deleted

С инсталляцией плагинов сложнее.

Если бы плагин можно было бы как-то инсталлировать, то вопрос о версии и актуальности плагина бы сразу отпал.

Плагин устанавливает пакетный менеджер. Понятное дело что при установке плагина через пакетный менеджер можно в скрипте установки дописать функцию добавления этого плагина в некую базу, но замучаешься поддерживать всё это добро. Установка по сути - перемещение плагина в определённый каталог файловой системы.

com
() автор топика

XXI-ый век, а загрузка динамической библиотеки в пользовательское приложение до сих пор платформо-зависима.

buddhist ★★★★★
()
Ответ на: комментарий от com

Если это пакеты, то кто таки мешает хранить инфу о плагине в файле, отдельном от самой либы?

Deleted
()
Ответ на: комментарий от user_2190

man dlopen -> RTLD_LAZY

у меня только что RTLD_LAZY рандомно на плагинах сыпался. Почему - оаяхз. С RTLD_NOW всё работает.

anonymous
()
Ответ на: комментарий от com

у тебя должен быть интерфейс для плагинов. При компиляции основного пакета в хидеры пихаешь версию собственно пакета + версию компилятора. При загрузке плагина проверяешь их. Если не совпадают - упс.

anonymous
()
Ответ на: комментарий от buddhist

с какой радости она там должна быть? Или ты из тех людей, которые стараются впихнуть в язык побольше разного говнеца, а потом жалуются на то, что написано всего полторы реализации, и те кривые.

anonymous
()
Ответ на: комментарий от anonymous

и все говно. dlopen стандартизирован (см. POSIX.1-2001).

Хорошая обертка есть в stlsoft: platformstl::module. Под *nix просто вызывает dlopen().

user_2190
()
Ответ на: комментарий от user_2190

это актуально только для адептов C++, но мы вроде как не о них сейчас. А libdl с dlopen() даже в венде нативно есть, так что смысла в обёртках никакого.

anonymous
()
Ответ на: комментарий от anonymous

Наверняка проблема в использовании. Может быть, -rdynamic, или еще какие-то опции компиляции; гадать не буду - нужно брать и отлаживать.

user_2190
()
Ответ на: комментарий от user_2190

нет, там сыпался рандомный плагин, а не каждый. Почему - я так и не смог отследить. Насчёт -export-dynamic и прочего я в курсе, поверь.

anonymous
()

посмотри, как сделано в vim

dimon555 ★★★★★
()
Ответ на: комментарий от anonymous

Я как раз-таки из тех, кто против :) Но на лоре любят трактора на уровне стандартов.

buddhist ★★★★★
()
Ответ на: комментарий от anonymous

Windows Services for UNIX

А, вот о чем речь. Раз речь зашла, поделитесь опытом - насколько удобно, много ли косяков, много ли нужно
уделять времени на сборку под них - если изначально писать и отлаживать проект под *nix?

Кросскомпиляция с *nix под винду с их использованием возможна?

user_2190
()
Ответ на: комментарий от user_2190

основные косяки идут из-за того, что оно старое как говно мамонта (там gcc3 в качестве цомпилера). Библиотеки тоже соответствуют. Но если писать изначально с учётом этой штуки, то страшных проблем возникнуть не должно. Правда, про большинство линупсовых библиотек придётся забыть.

anonymous
()
Ответ на: комментарий от anonymous

gcc3..
А использовать виндовые библиотеки одновременно с этими можно?

Старое как говно мамонта

MS вообще его еще поддерживает?

user_2190
()
Ответ на: комментарий от user_2190

А использовать виндовые библиотеки одновременно с этими можно?

можно.

MS вообще его еще поддерживает?

не-а. Последняя версия вышла 5 лет назад. Я бы забил болт и использовал mingw или писал с расчётом на msvc.

anonymous
()

Я бы сделал отдельный вызов типа getPluginInfo() и через него всё возвращал. Да, возможно, это будет на какие-то миллисекунды медленнее, это проще, надёжнее и универсальнее, чем заморачиваться с зипами и текстовыми файлами. Кстати, зип, мне кажется, убьёт весь выигрыш в быстродействии.

hobbit ★★★★★
()
Ответ на: комментарий от buddhist

Есть платформонезависмые решения - Qt, SDL. Но они тянут за собой ещё много чего.

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

и все говно.

Обоснуй.

dlopen стандартизирован (см. POSIX.1-2001).

Скажи это Micro$oft.

Deleted
()
Ответ на: комментарий от anonymous

А libdl с dlopen() даже в венде нативно есть, так что смысла в обёртках никакого.

Сделай мне развидеть это.

Deleted
()
Ответ на: комментарий от anonymous

Это проблема операционной системы.

И мы все знаем эту операционную систему!:))

Pavval ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.