Внимательно прочитай вопрос, на который был мой ответ.

Если позволяет архитектура, такой флажок можно завести в объекте-источнике ( sender() ).

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

Принцип бритвы Оккама - самое простое решение является самым правильным. 

Хе... Заметил попутно такой факт, не совсем в тему, но в принципе можно было бы использовать и тут - если класс хранения переменной в плагине статический (static, или глобально без модификатора, или extern), и плагин загружается из той же DLL повторно, то эта переменная будет общей для всех загруженных версий плагина (динамическая память и стек у каждого будут, разумеется, свои). Но если плагин загрузить с таким же кодом, но из DLL с другим именем (из копии файла DLL), то статически хранимые переменные будут для всех версий свои. По крайней мере, так в вениках. Как в Линухе еще не знаю, до сборки проекта в нем еще далеко.

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

Да, нашел уже описание. Странно, что раньше это не попадалось.


Я имел в виду - разные. Это понятно, что у приложения куча одна и стек один.


Это если 5 разных процессов. Я имел в виду случай загрузки одной DLL несколько раз одним и тем же процессом. Статические данные вместе с кодом отобразились один раз, и как вы выше сказали, затем только увеличивается счетчик использования - не только сегмента кода, но и сегмента данных.


Вот это теперь для меня вполне обоснованно.

Сижу теперь и думаю, что в реальной жизни будет лучше, если по условию для каждого плагина надо иметь собственные сегменты данных - плодить копии плагинов и грузить их как отдельные, либо переделывать плагины, чтобы у них не было статических данных, все только динамические. Первый вариант проще. Но это приведет к многократной загрузке и дублированию в памяти одинакового кода, хотя он и не страшно смертельного объема, около 800 КБ на плагин, но может вырасти до 2 МБ. Максимум в реальности будет загружаться 10-20 таких плагинов. В принципе, не смертельно. Но надо еще придумать, как и когда создавать копии. Второй вариант - это переделка всего такого плагина, а он... сложный. И давно написанный и хорошо отлаженный. И статические данные там неспроста появились.

Именно о параллельном выполнении и речь. Переделывать плагины пока не стал, хотя оно все тут же, связано зависимостями с проектом, и можно менять. Но сделал пока простой вариант - автоматически при необходимости на носителе создаются копии плагина, которые загружаются. Если копия уже есть, то просто загружается, не создается. Просто надо другое делать, всего делать вообще дофига, а переделка задержит на неопределенное время. Там в плагинах сложно, около 15000 строк... В следующей версии можно будет и переделать, если понадобится, это как отдельная задача фактически.