Проектирую структуру кросплатформенного (Windows и Linux) многопоточного приложения.
С программированием под Linux знаком мало (работал только с QT под обоими платформами).

Собственно задача:
Необходимо посылать сообщения из функций, находящихся в динамических библиотеках (поток для них создает исполняемый файл).

Если бы писал только под Windows то было бы оптимально PostThreadMessage или Post/SendMessage и цикл обработки сообщений потока/окна.
Пока только приходит в голову callback функция в исполняемом файле, которая помещает данные сообщения в потокобезопасный контейнер и генерирует собщение, что его в контейнере есть данные. Так как она находится в исполняемом файле то смело можно использовать сообщения QT, на котором я планирую создавать интерфейс.

P.S. Желательно также, чтобы метод позволял разрабатывать динамические библиотеки не только на С.

Qt вполне позволяет соединять сигналы со слотами из других потоков:

Отлично это знаю, а если динамическая библиотека разрабатывается на другом языке (например Delphi). Так как библиотеки планируется применять как модули расширения - плугины.
Надо чтото более универсальное, хотябы с использованием стандартной библиотеки С++.

удалено

Это сообщение отредактировал(а) Alek86 - 13.8.2008, 10:11

Универсальное? А что есть и в Линуксе и Виндовс? 
Например socks. Правда при работе с socks все равно придется некоторые участки кода обрамлять в  #ifdef WIN32

если длл может писаться на любом языке и под любые платформы, то подойдет только общая технология типа COM (не знаю. правда. как он реализуется под линухом) или .Net

Gwendolen, вопрос я понял плохо. Могу сказать, что во-первых, надо понять, что бинарной переносимости между win32 и linux нет, и ничто это не исправит: нужно делать разные сборки под разные платформы. Переносимости на уровне исходных кодов можно добиться за счет использования библиотек (Boost, в частности, его потоковая библиотека, Qt, wxWidgets...). 

Если вы создаете распределенное приложение, часть которого выполняется на одной платформе, часть на другой, то взаимодействие между ними можно организовывать традиционными средстванми: сокеты, ICE, недавно опубликованная Google Protocol Buffers из бинарных или XML-RPC, web servicies из текстовых. 

COM и CORBA, если ничто извне не вынуждает их использовать, это оверкил: очень сложные, поддержка есть только для COM под Windows, в остальных сочетаниях вам придется довольно тяжко (хотя и в случае COM под win32 все тоже тяжко). Ничего особо эксклюзивного они сами по себе не представляют (имеет смысл использовать, повторю, если есть уже что-то на них написанное).

Это сообщение отредактировал(а) Ulysses4j - 13.8.2008, 15:32

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

Похоже код, прийдется разделять и для потправки сообщений использовать API конкретной ОС (не обработку сообщений с помощью каких либо библиотек).

Если спользовать API конкретной ОС, переносимости кода не будет, надо использовать API какой-либо библиотеки-обертки над API ОС.

А вот это как раз не желательно.

В принципе продолжение темы корректней продолжить здесь:
Обработка сообщений на Linux, Нужны API функции

Чё то я не врубаюсь.  
Похоже что автор сам еще не знает что ему нужно, или не знает нужно ли ему хоть что-то...
Ну понаблюдаем...
Я думаю автору статьи нужно написать абсолютно новую ОС. На которой будет API Windows, но на самом деле это Linux. Или наоборот.
Это единственное решение.  

Это сообщение отредактировал(а) andrew_121 - 15.8.2008, 01:55

WINE - и ничего писать не нужно  

bsa, Извращение какое-то  

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