shared DLL, linux?

А зачем?!?

Так сложно нормальный PIC-код изрыгнуть?

> т.е. два различних процесса могут загружать одну и > ту же DLL в одно и то же адресное пространство.

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

> А зачем?!?

1. http://carrot.cern.ch/

apache 1.3 (apache2 - multithreaded, поэтому такая проблема
не стоит) - это "sub-processes farm". Родительский process
порождает childs. Каждый request, приходящий на server отрабатывается одним из child process. Если детей не хватает
- рождается еще один ублюдок (ну, прям как мать-героиня).
Каждый новорожденный копирует наследство родителя, включая
loaded DLL code, которое подчас "невыносимо тяжелое".
Именно поэтому, PHP, carrot etc. такие "тяжелые".
Было бы неплохо копировать только data, DLL data, a DLL code
оставлять "shared between childs", как это делается в
"shared DLL under M$ windows".

2. shared memory for C++ objects.

Нет проблем сделать "interprocess shared memory" для
"plain C structures". С C++ objects сложнее, потому что
pointers to virtual table у обьектов одного и того же класса
в разных процессах отличаются. Именно потому, что DLL codes
в разных процессах находятся в разных адресных пространствах.

Имея shared DLL позволило бы решить и эту проблему.

Воoбще, вопрос "А зачем?!?" - дурацкий,
и похож на тот, который приходится часто слышать -
"а за чем нужна наука?"

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

популярно показано здесь -
http://www-w2k.gsi.de/labview/NI-InstrumentDriver/GlobalMemory/globalmemory.htm

Shared ... не DLL data, но DLL code

2Valeriy_Onuchin:

1. Очень прошу воздержаться от ответов на оскорбительные выпады. Если есть желание получить ответ, настоятельно рекомендую игнорировать оскорбительные посты -- они будут удалены вместе со всеми последующими комментариями.

2. Не надо ничего делать. Линукс сам разделит код, если можно. Просто dlopen на PIC код не будет загружать лишнюю копию, а будет использовать ту, что уже в памяти.

А вот если НЕ PIC, то он попытается загрузить еще одну копию, но, скорее всего, сглючит из-за багов (просто мало кому надо позишендепендент разделяемый код, поэтому Линух в этом месте не отлажен).

> Shared ... не DLL data, но DLL code

как уже сказал Die-Hard он и так всегда shared,
непонятно почему вы вообще в этом усомнились.

> популярно показано здесь -
> http://www-w2k.gsi.de/labview/NI-InstrumentDriver/GlobalMemory/globalmemory.htm


:))) кому популярно, а меня такие красивые картинки только
запутывают. я могу предложить 10 интерпретаций сопровождающему
их тексту.

> А вот если НЕ PIC, то он попытается загрузить еще одну копию,
> но, скорее всего, сглючит из-за багов (просто мало кому надо
> позишендепендент разделяемый код, поэтому Линух в этом месте
> не отлажен).

не должен сглючить. эта возможность _подерживается_. Вы совершенно
правы в том, что будет еще одна копия (просто потому, что dynamic
linker вынужден будет писать в сегмент кода разрешая не relocatble
ссылки) и в том, что это мало кому нужно.

тем не менее, это иногда может быть полезно. для скорости, например.
pic имеет некоторые накладные расходы (а иногда даже просто занятый
ebx может быть проблемой), поэтому иногда можно пожертвовать скоростью
загрузки и лишней памятью (которая в этом случае имеет swap как
backing store).

я сам так делал в те времена когда эти 5% в моем случае играли свою
роль :)

> Вы совершенно правы в том, что будет еще одна копия

btw, даже в этом случае мы не будем терять память при fork().
насколько я помню non pic код разрешается в non lazy манере,
так что после загрузки библиотеки у нас не будет туда stores.

> не должен сглючить. эта возможность _подерживается_.

что-то я в нетрезвом виде окончательно потерял способность
ясно выражаться :)

поддерживается это для i386, про остальные не скажу, хотя
думаю, что да.

и вообще это проблема не Linux, а binutils, единственное
участие которое принимает в этом деле ядро - это реализация
mmap().

да, есть знаменитый после обнаруженной в нем ошибки sys_uselib,
но это анахронизм. вся работа выполняется /lib/ld-linux.so

2idle (кстати, почти знакомы уже -- может, на "ты" перейдем?):

> не должен сглючить. эта возможность _подерживается_.

Я пробовал так:

Начитавшись того, что это поддерживается, просто компилил в .so без -fpic, и смотрел, что будет. Правда, несколько лет назад последний раз такое пробовал; может, все повылизали... Иногда работало, иногда -- в segfault валилось. Причем, в прямой зависимости от сложности (величины) сгенеренного .so модуля, сегфолт наблюдался чаще.

Только поэтому я и сделал эту оговорку.

2idle:

> насколько я помню non pic код разрешается в non lazy манере

У!!!

Я же с полгода назад спрашивал Вас, как избежать lazy при форке (мне это было важно в свете ccNUMA), и Вы тогда сказали, что практически никак!

> > насколько я помню non pic код разрешается в non lazy манере
>
> У!!!
>
> Я же с полгода назад спрашивал Вас, как избежать lazy при форке

ну говорю же, пьяный :)

я вот чего имел в виду.

если грузится pic сегмент, то ссылки разрешаются по мере вызова
функций, lazy.

если в сегменте присутствуют ... эти, не помню как их правильно,
ну вы поняли :) то динамик линкер будет делать relocations сразу
и всех при загрузке библиотеки. поэтому при последующем fork()'е
никаких cow и дополнительных расходов на память уже не будет, тк
туда уже никто не будет писать.

отныне обещаю заходить сюда только трезвым!

> Иногда работало, иногда -- в segfault валилось.

охотно верю. поддерживается - не означает что еще
и без ошибок :)

2idle:

> если грузится pic сегмент, то ссылки разрешаются по мере вызова функций, lazy.

>если в сегменте присутствуют ... эти, не помню как их правильно, ну вы поняли :) то динамик линкер будет делать relocations сразу и всех при загрузке библиотеки.

Понял :)

Действительно, немного не то, что мне было нужно...

Может я чего-то не понимаю. В есть граница между процессами,
которая не позволяет шарить код, дата между процессами,
т.е. DLL code в разных процессах всегда физически
лежит в разнуых местах памяти у двух разных процессов,
независимо PIC он, или non-PIC.

То, о чем я спаршиваю:
нужен shared_memory_cache_manager, который бы занимался
allocate/deallocate DLL code in shared memory,
ref_counting etc. А также shared_memory_dlopen,
shared_memory_dlclose, которые бы взаимодействовали с этим
shared_memory_cache_manager.

В M$ Windows - это есть реализовано на уровне системы.
На сколько я понимаю ничего подобного в linux - НЕТ (?!).

Могу ошибаться ....

> Может я чего-то не понимаю. В есть граница между процессами,
> которая не позволяет шарить код, дата между процессами,

теперь я ничего не понимаю.

> т.е. DLL code в разных процессах всегда физически
> лежит в разнуых местах памяти у двух разных процессов,
> независимо PIC он, или non-PIC.

пожалуйста, постарайтесь формулировать вопросы точнее.

dll code "лежит" физически в "одном месте". но виден
он под разными виртуальными адресами в разных процессах.

это вообще вопрос не про dll, а про mmap. я точно помню,
на этом форуме все это уже обсуждалось, попробуйте поискать.

> А также shared_memory_dlopen, shared_memory_dlclose

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

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

попытемся методом "вопрос - ответ"

>dll code "лежит" физически в "одном месте". но виден
>он под разными виртуальными адресами в разных процессах.

означает ли это, что существует механизм учета сколько
процессов загрузило данную DLL в память, для того, чтобы
освободить память, когда не осталось процессов "пользующих"
эту DLL (so called ref_counting)?

>> А также shared_memory_dlopen, shared_memory_dlclose

>я думаю, не все на этом форуме знают, что это такое. я - нет

"shared_memory_dlopen, shared_memory_dlclose" - попытка
дать название несуществуюшим отражающе желаемую
функциональность.

>кода библиотеки зачем-то загружался всегда в одинаковый
>адрес для всех процессов, это можно, кажется сделать
>с помощью ld

кажется или можно?
с помощью def file, с указанием "base address"?
есть ли под linux?

>это вообще вопрос не про dll, а про mmap. я точно помню,
>на этом форуме все это уже обсуждалось, попробуйте поискать.

постраюсь найти. если знаете где, ссылку пожалуйста.

спасибо

> означает ли это, что существует механизм учета сколько
> процессов загрузило данную DLL в память, для того, чтобы
> освободить память, когда не осталось процессов "пользующих"
> эту DLL (so called ref_counting)?

да. только нет никакого ref_counting. учетом занимается
не какой-то dll менеджер, а ядро. причем ядро понятия
не имеет о том, что это код из dll.

то есть счетчик есть конечно, но относится он к файлу.
а fvs в свою очередь и не подозревает, что это - dll.

еще раз, вам нужно понять что такое mmap, после этого
все подобные вопросы отпадут.

> кажется или можно?
> с помощью def file, с указанием "base address"?
> есть ли под linux?

кажется, не уверен. разбирайтесь c ldscript, где найти
инфу не знаю. в принципе это точно возможно, иначе бы
prelinking нельзя было бы сделать.

удовлетворите мое любопытство, зачем это нужно?

А man mmap почитать - религия мешает?

Определённо, C++ людям мозги портит...

ууух ... похоже глупейший вопрос задал :-(

диагноз - "обчитался книжек по M$ windows"
деиствительно, все DLL are shared под linux by default.

хотя вопрос был спровоцирован как раз mmap и
http://www.linux.org.ru/view-message.jsp?msgid=856250

дело в том, что у нас есть такой класс
http://root.cern.ch/root/htmldoc/src/TMapFile.cxx.html
с перегружаемыми "global new/delete", которые создaют
обьекты с помощью mmalloc/mfree

В настоящей реализации общение через mmap происходит
с помошью writing object into shared memory from one
process -> reading/clonning this object from shared memory
from another process.

Хотелось бы иметь REALLY SHARED OBJECT between two processes.
В принципе, это было бы возможно, если бы не
"виден он под разными виртуальными адресами в разных
процессах" ...

т.е. я создаю обьект в одном процессе, при етом создается
указатель на pointers to functions (to DLL code),
а в другом процессе этот указатель смотрит в совсем другое
место

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

> т.е. я создаю обьект в одном процессе, при етом создается
> указатель на pointers to functions (to DLL code),
> а в другом процессе этот указатель смотрит в совсем другое
> место

да это замучаешься делать учитывая таблицу виртуальных
функций да и многое другое.

не надо вам связывать обьект, выделите _данные_ которые
действительно должны быть SHARED. и работайте с этими
данными с помощью - уж коли раз C++ - экземпляра helper
класса, сам же обьект пусть в разных процессах по разному
адресу будет. сами же данные можно разместить и по одному
адресу с помощью mmap(MAP_FIXED).

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

то, о чем вы только что написали именно и есть наш дизайн.

проблема только с "таблицу виртуальных функций", указатель на которую различен для разных процессов.

> проблема только с "таблицу виртуальных функций",
> указатель на которую различен для разных процессов.

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

или я вас все таки неправильно понял, или вы меня.

OK, let's stop here

спешил на meeting, забыл сказать - спасибо 2idle

++
TMapFile - действительно надо переделать, как вы сказали.
К тому же, его M$ windows не работает сейчас - надо сделать.

прошу прощения, только сейчас заметил....

> 2idle (кстати, почти знакомы уже -- может, на "ты" перейдем?):

с удовольствием :)

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

2idle:

> прошу прощения, только сейчас заметил....

:-)

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

Я раньше (в другой сетевой инкарнации) был со всеми на "Вы", как в научной среде принято. Но потом выяснилось, что многие ...обижаются! Как мне популярно объяснили, обращение на "ты" к "нику" вполне вписывается в правила "нетикета". К сожалению, в действительности люди порой обижаются...

Кстати, по моим наблюдениям в "физических" письмах принято обращение на "Вы" (типа, "Dear Prof. ***"). Исключение -- голландцы и половина американов. А ИТшники/фирмачи в _лучшем_ случае пишут "Hello!", обычно же -- просто "Hi!"

я к своему начальнику (французу, для них этикет имеет большe'e
значение) обращаюсь на You.
Но, для меня you - это всегда "ты" :-)
что для него это значит не знаю. надеюсь тоже самое :-)