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

Сюда!

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

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

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

???

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

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

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

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

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

???

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

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

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

Да.

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

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

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

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

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

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

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

И zip может работать без компрессии.

Тогда лучше файл сам по себе. Зачем лишний контейнер?

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

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

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

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

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

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

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

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

man dlopen -> RTLD_LAZY

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

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

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

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

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

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

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

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

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

Можно юзать кроссплатформенные либы-обертки, коих 100500 :)

Я про язык и его стандарт :)

man dlopen -> RTLD_LAZY

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

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

кончай гнать ахинею, язык тут не причём. Это проблема операционной системы.

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

Как это не причем? При том, что в стандарте С нет подобной функции.

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

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

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

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

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

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

Ясно.

По поводу libdl:

http://code.google.com/p/dlfcn-win32/issues/detail?id=6

btw I will no longer maintain this project, so if anyone CAPABLE wants to maintain it, let me know...
this also means the new maintainer can add all sorts of crazy extensions (preferably configurable, the default being posix).

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

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

зачем это нужно? Есть Windows Services for UNIX с полноценной libdl и шлюхами.

Windows Services for UNIX

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

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

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

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

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

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

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

можно.

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

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

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

Ясно, спасибо.

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

В C и C++ в стандарте вообще никаких упоминаний про либы и прочие.

и все говно.

Обоснуй.

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

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

и все говно.

Poco::SharedLibrary - не говно.

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

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

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

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

посмотрел в доки. dlopen обёрнутый в класс. Зачем это?