CommFort

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

И первый вопрос:
Судя по тому как я понял - импортируемые функции (CommFortProcess и CommFortGetData) должны вызываться только в основном потоке?
Если да, то выскажите пожалуйста свои способы наиболее оптимальной синхронизации потоков.

Можем реализовать описанный здесь метод: http://wiki.qip.ru/Создание_многопоточного_плагина . То есть плагин из дополнительного потока посылает программе сообщение, а программа в момент обработки этого сообщения из основного потока вызовет дополнительную функцию плагина.

Тут собственно не проблема организовать запуск функции из основного потока. Просто надо где-то хранить данные, которые понадобятся функции.
Допустим мне надо вызвать функцию выхода пользователя из чата. Для этого я должен сформировать строку в соответствии с API с его ником. Но где хранить эту строку?

Есть 2 варианта, которые можно реализовать хоть сейчас:
1. Определить функцию стандартными средствами C++ Builder, которая будет обработчиком PostMessage/SendMessage. Послать со второго потока через SendMessage указатель на сформированную для API строку, а основной поток получит сообщение, вызовет нашу функцию и передаст ей параметром указатель на строку, а потом выполнит запрос к серверу.
Плюс - самая простая реализация.
Минус - второй поток будет ждать пока основной поток выполнит функцию.
2. Определить функцию стандартными средствами C++ Builder, которая будет обработчиком PostMessage/SendMessage. Поместить в какой-то список строку, которую надо отослать серверу и вызвать PostMessage, который вызовет функцию, которая в свою очередь пройдется по списку и отошлет серверу все запросы.
Плюс - второй поток не ожидает выполнения функции (особенность PostMessage).
Минус - для доступа к списку придется делать блокирование (можно Критическими секциями), которое опять же может заставить второй поток ждать.

Как видно везде есть недостатки... Что можете предложить?

После отправки сообщения программе и вплоть до выполнения специальной функции в основном потоке дополнительный поток должен приостанавливаться. Это защитит от попытки доступа к данным с разных потоков.

Да, это самый надежный способ, но не самый быстрый. Чуть быстрее - PostMessage, но его реализация сложнее и прийдется использовать список с блокированием доступа.
Кстати, а на сколько быстро выполняются запросы к плагину на подключение и отключение пользователей?

Да, это самый надежный способ, но не самый быстрый.

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

Кстати, а на сколько быстро выполняются запросы к плагину на подключение и отключение пользователей?

Не совсем понятен вопрос.

Maxim Mirgorodsky писал(а):

Кстати, а на сколько быстро выполняются запросы к плагину на подключение и отключение пользователей?

Не совсем понятен вопрос.

На сколько быстро происходит возврат из импортируемой функции CommFortProcess при передаче ей id действий 1001 и 1002 и остальных параметров?

Функция выполняется асинхронно, то есть возврат происходит сразу.

Maxim Mirgorodsky писал(а):Функция выполняется асинхронно, то есть возврат происходит сразу.

Это особенность импортированных функций или вы сами реализовали асинхронность?

Сами.