LINUX.ORG.RU

Выгрузка so'шки из пространства процесса

 


0

2

Здороваться не будем, сразу к делу - есть некий процесс/движок, который модульный и многопоточный, модули/плагины/so подцепляются/отцепляются в рантайме из любого ядра, в плагинах тоже крутится поток. В общем среда конкурентная,

Проблема вот в чём - из описания dlclose понятно, что завершение её вообще не гарантирует, что модуль выгрузился. В теории и промежутки между загрузить/выгрузить могут быть сколь угодно малыми. Как бы не получить какие-то битые данные в образе плагина (старый не успел выгрузиться, записи с другого ядра в каком-нибудь буфере ждут, а тут запрос на добавление плагина с последующей записью на другом ядре).

Можно ли как-то точно узнать, что плагин полностью выгрузился из адресного пространства, следующий dlopen даст девственно «чистую» память под сошкой? Т.е. я дернул dlclose, за что мне потом дергать в цикле чтобы понять, что процедура завершена полностью?


Кстати, а могу ли я загрузить сошку несколько раз? Там же есть dlmopen с отдельными неймспейсами/линкмепами, если каждую грузить в свой, то будут независимые экземляры? Надо проверить.

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

Проблема вот в чём - из описания dlclose понятно, что завершение её вообще не гарантирует, что модуль выгрузился.

dlclose вообще может быть пустой заглушкой, в зависимости от libc

annulen ★★★★★
()

Реализуй управление исполнением отдельно от управления подгрузкой so. Для данных соответственно функцию, их инициализирующую вызывай, храни состояние («запущен/не запущен»), не связанное с подгрузкой, и оберни всё в мютекс.

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

Загрузил в новый линкмеп через dlmopen, в итоге сошка попала в абсолютно пустое пространство, где нет даже главного приложения (оно -rdynamic). Такая история мне не подходит, мне нужно делить данные между главным модулем и плагинами, тягать клубок ссылок на окружение - не подходит.

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

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

Хотя наверняка можно накидать в новый линк мэп, которые создался через dlmopen, нужные модули.

Спасибо.

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

и оберни всё в мютекс.

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

kvpfs_2
() автор топика
Последнее исправление: kvpfs_2 (всего исправлений: 2)
Ответ на: комментарий от firkax

Ну там немного запутанно, подцепляется плагин в однопотоке (dlopen+вдуть поток взятый у thread_pool), создаётся shared_ptr на интерфейс к этому хозяйству, другие потоки берут при необходимости, последний деражтель shared_ptr прибивает поток и выгружает плагин. В общем проблему я из пальца высосал, в плагине своя синхронизация, там битого состояния быть не может.

Мне вот ещё интересно, можно ли подгрузить один и ту же сошку в главный линк мэп несколько раз? Ну не копируя файл либы.

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

Мне вот ещё интересно, можно ли подгрузить один и ту же сошку в главный линк мэп несколько раз? Ну не копируя файл либы.

Даже если где-то и получится то это будет чревато багами и некроссплатформенно. И даже если so с одинаковыми именами но отличаются только путями - лучше тоже так не делать по-моему.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Звучит странно, да. Но это что-то вроде юзерских программок, которые могут быть запущены в нескольких экземлярах над разными объектами. Странно требовать не использовать глобальных переменных или не забывать thread_local.

Что-то мудрить с этими отдельными линк мепами надо, скопировать все модули из главного линк мепа и потом подгружать туда плагин. В общем увлекательно

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

А память освобождать не?

А то так и будем 40 лет таскать костыль под simcity for win 3.11. Которая как раз и уповала на поведение той самой win 3.11, что память не освобождается после free(). Ну и все, приехали, во всех шиндах с эмуляцией 16bit таскали затычку под эту хрень.

harbinger
()