Pzz>>ну по-моему, в man dlmopen все достаточно ясно написано
A>читаю такое: "В реализации glibc поддерживается до 16 пространств имён."
м-да, линукс такой линукс... ну значит dlmopen не катит

Здравствуйте, alexraynepe196, Вы писали:

A>Здравствуйте, SaZ, Вы писали:

A>>>Единственное решение обойти это место, я пока нашел — скопировать файл библиотеки в несколько независимых, и загружать эти библиотеки как независимые, получится одна библиотека/одоно устройство.

SaZ>>Сделайте процесс-обвёртку вокруг вашей .dll и запускайте столько инстансов, сколько надо. Общайтесь через любой IPC. Да, производительность чуть просядет, но для эмулятора должно подойти.

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

Решается через shared memory. Насколько у вас критичны требования к быстродействию эмулятора?

Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, alexraynepe196, Вы писали:

A>>Здравствуйте, SaZ, Вы писали:

A>>>>Единственное решение обойти это место, я пока нашел — скопировать файл библиотеки в несколько независимых, и загружать эти библиотеки как независимые, получится одна библиотека/одоно устройство.

SaZ>>>Сделайте процесс-обвёртку вокруг вашей .dll и запускайте столько инстансов, сколько надо. Общайтесь через любой IPC. Да, производительность чуть просядет, но для эмулятора должно подойти.

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

SaZ>Решается через shared memory. Насколько у вас критичны требования к быстродействию эмулятора?
Так ради быстродействия весь топик и заведен. Сейчас уже есть рабочее решение, без ИПК вполне пыхтит.

Может быть я непрявильно понял постановку задачи, но разве простой fork() не решает задачу? Если верить книгам, то Android делает (или делал) именно так: запускается первородный экземпляр JVM, который форкается при запуске каждого пользовательского приложения. Поскольку в Linux fork() реализован через copy-on-write, то уже загруженные системные классы делятся между экземплярами разных JVM, тогда как код приложений (и данные, очевидно) остаётся изолированным.

Здравствуйте, alexraynepe196, Вы писали:

A>3) в текущей реализации загружается библиотека, а для каждого экземпляра хранится копия области данных используемая библиотекой. Исполняемый код остается общим. Для выполнения кода над конкретным экземпляром — область данных библиотеки перезаписывается из контейнера экземпляра.

Библиотека чужая? Перекомпилировать с отвязкой от глобальных данных — никак?
А то постановка вопроса выглядит совершенно дикой, потому что привычно, что есть объект "контекст" (как бы он ни назывался), из которого ссылки на все данные.

A>Единственное решение обойти это место, я пока нашел — скопировать файл библиотеки в несколько независимых, и загружать эти библиотеки как независимые, получится одна библиотека/одоно устройство.

Они не дерутся за одноимённые экспортируемые имена?

A>MMU современных процессоров с другой стороны просто предназначено для решения подобных задач — достаточно создать несколько сегментов данных — по одному на каждое устройство, и переключать эти сегменты при исполнении одного общего сегмента кода. Но как это сделать реально?

Звать mmap() на такое будет явно ещё дороже.

Зачем такие извращения вообще были нужны?

Здравствуйте, cppguard, Вы писали:

C>Может быть я непрявильно понял постановку задачи, но разве простой fork() не решает задачу? Если верить книгам, то Android делает (или делал) именно так: запускается первородный экземпляр JVM, который форкается при запуске каждого пользовательского приложения. Поскольку в Linux fork() реализован через copy-on-write, то уже загруженные системные классы делятся между экземплярами разных JVM, тогда как код приложений (и данные, очевидно) остаётся изолированным.

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

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, alexraynepe196, Вы писали:

A>>3) в текущей реализации загружается библиотека, а для каждого экземпляра хранится копия области данных используемая библиотекой. Исполняемый код остается общим. Для выполнения кода над конкретным экземпляром — область данных библиотеки перезаписывается из контейнера экземпляра.

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

N>А то постановка вопроса выглядит совершенно дикой, потому что привычно, что есть объект "контекст" (как бы он ни назывался), из которого ссылки на все данные.

A>>Единственное решение обойти это место, я пока нашел — скопировать файл библиотеки в несколько независимых, и загружать эти библиотеки как независимые, получится одна библиотека/одоно устройство.

N>Они не дерутся за одноимённые экспортируемые имена?
Дерутся. НО обеспечить разные имена для пары методов АПИ моделера можно, этим и пользуются — моделируемый код собирается в обертке, которая предоставляет АПИ для моделируемого класса.
Пока я моделирую для разных классов по одному устройству — вопросов нет. Когда надо смоделить сотню устройств одного класса — вот о чем задача.

A>>MMU современных процессоров с другой стороны просто предназначено для решения подобных задач — достаточно создать несколько сегментов данных — по одному на каждое устройство, и переключать эти сегменты при исполнении одного общего сегмента кода. Но как это сделать реально?

N>Звать mmap() на такое будет явно ещё дороже.

N>Зачем такие извращения вообще были нужны?

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

Здравствуйте, alexraynepe196, Вы писали:

A>>>3) в текущей реализации загружается библиотека, а для каждого экземпляра хранится копия области данных используемая библиотекой. Исполняемый код остается общим. Для выполнения кода над конкретным экземпляром — область данных библиотеки перезаписывается из контейнера экземпляра.
N>>Библиотека чужая? Перекомпилировать с отвязкой от глобальных данных — никак?
A>Библиотека то своя, но постановказадачи — симуляция продукта, и он должен быть максмально приближенным к проду.

Неужели на "проде" обязательно использовать глобальные переменные подо всё? Что-то слабо верится.

A> Переделывать архитектуру под моделирование никто не станет.

То есть о том, что продукт должен быть тестируемым, никто не в курсе и никого это не интересует?
А в реале у вас невозможно иметь более одного подключенного устройства каждого типа? Даже два не бывает?
Всё это настолько дико звучит...

N>>Зачем такие извращения вообще были нужны?
A>примерно затем же для чего и системы виртуализации, тока безопасность ненужна.

Здравствуйте, alexraynepe196, Вы писали:

SaZ>>Решается через shared memory. Насколько у вас критичны требования к быстродействию эмулятора?
A>Так ради быстродействия весь топик и заведен. Сейчас уже есть рабочее решение, без ИПК вполне пыхтит.

Ок, тогда извините, пока мыслей нет.

Здравствуйте, alexraynepe196, Вы писали:

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

не выглядит. Разве устройства общаются друг с другом ? Как я понял, не хочется утеделять только вызовы методов устройства, комз туча (мначе не было бы разгоаоров о копировании). Пусть себе сидят в изолированных процессах. И тестируются независимо.

если уж очень надо — шаред мапинг RW. Он будет отнаследован всеми потомками. Никакого копирования — одни и те де страницы отображены в разные АП