
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.14.89] |
![]() |
|
Сообщ.
#1
,
|
|
|
Всем привет!
Представляю модуль для работы с многопоточностью на VB6 для Standard EXE проектов. Данный модуль разработан на основе этого решения в котором исправлены некоторые баги и добавлен дополнительный функционал. Модуль не требует никаких дополнительных зависимостей и библиотек типов, работает как в IDE (все функции работают в главном потоке) так и в скомпилированном виде. https://www.youtube.com/watch?v=D1-3PlAoEnk Для начала работы с модулем нужно вызывать функцию Initialize, которая инициализирует данные необходимые для работы (инициализирует критические секции для монопольного доступа к куче хидеров и потокам маршалинга, модифицирует VBHeader (тут написано для чего), выделяет TLS слот для передачи параметров потоку). Основная функция создания потока - vbCreateThread которая является аналогом функции CreateThread. ![]() ![]() ' // Create a new thread Public Function vbCreateThread(ByVal lpThreadAttributes As Long, _ ByVal dwStackSize As Long, _ ByVal lpStartAddress As Long, _ ByVal lpParameter As Long, _ ByVal dwCreationFlags As Long, _ ByRef lpThreadId As Long, _ Optional ByVal bIDEInSameThread As Boolean = True) As Long Функция создает поток и вызывает функцию переданную в параметре lpStartAddress с параметром lpParameter. В IDE вызов сводится к простому вызову по указателю реализованному через DispCallFunc. В скомпилированном варианте данная функция работает по-другому. Т.к. для работы потока требуется инициализация проектно-специфичных данных, а также инициализация рантайма, параметры переданные в lpStartAddress и lpParameter временно сохраняются в куче посредством функции PrepareData, а поток создается в функции ThreadProc, которая занимается непосредственно инициализацией и вызовом уже пользовательской функции с пользовательским параметром. Данная функция создает копию структуры VBHeader через CreateVBHeaderCopy и изменяет данные размещения публичных переменных в структурах VbPublicObjectDescriptor.lpPublicBytes, VbPublicObjectDescriptor.lpStaticBytes (что не было сделано в предыдущем варианте) так чтобы глобальные переменные не затрагивались при инициализации. Далее VBDllGetClassObject вызывает функцию FakeMain (адрес которой записан в модифицированную структуру VBHeader). Для передачи пользовательских параметров используется TLS слот (т.к. функция Main не принимает параметры, подробности тут). В FakeMain уже параметры извлекаются из TLS и вызывается пользовательская процедура. Возвращаемое значение функции также передается обратно через TLS. Тут есть один интересный момент связанный с копией хидера, который был не учтен в предыдущей версии. Т.к. рантайм использует хидер после завершения потока (при DLL_THREAD_DETACH) мы не можем освободить хидер в процедуре ThreadProc, и произойдет утечка памяти. Для предотвращения утечки памяти используется куча фиксированного размера, хидеры не очищаются пока есть место в этой куче. Как только место заканчивается (а оно выделяется в функции CreateVBHeaderCopy) происходит очистка ресурсов. Первый DWORD хидера на самом деле хранит ID потока в котором был создан и в функции FreeUnusedHeaders происходит проверка всех хидеров в куче. Если поток завершен - место освобождается (хотя ID может повторятся, но это не играет особой роли т.к. в любом случае в куче будут свободные места и если хидер не освободился в одном случае то он будет освобожден позже). Из-за того что очистка может быть вызвана сразу из нескольких потоков доступ к очистке разделяется критической секцией tLockHeap.tWinApiSection и если какой-то поток уже занимается очисткой функция возвратит True что означает что вызывающий поток должен немного подождать и память будет доступна. Еще одной из возможностей модуля является возможность инициализации рантайма и проекта и вызова callback-фнкции. Это может пригодится для сallback-функций которые могут быть вызваны в контексте произвольного потока (к примеру InternetStatusCallback). Для этого служат функции InitCurrentThreadAndCallFunction и InitCurrentThreadAndCallFunctionIDEProc. Первая функция используется в скомпилированном приложении и принимает адрес функции обратного вызова которая будет вызвана после инициализации рантайма, а также параметра который будет передан в эту функцию. В callback-процедуре передается адрес первого параметра чтобы потом в пользовательской процедуре ссылаться на него: ![]() ![]() ' // This function is used in compiled form Public Function CallbackProc( _ ByVal lThreadId As Long, _ ByVal sKey As String, _ ByVal fTimeFromLastTick As Single) As Long ' // Init runtime and call CallBackProc_user with VarPtr(lThreadId) parameter InitCurrentThreadAndCallFunction AddressOf CallBackProc_user, VarPtr(lThreadId), CallbackProc End Function ' // Callback function is called by runtime/window proc (in IDE) Public Function CallBackProc_user( _ ByRef tParam As tCallbackParams) As Long End Function CallBackProc_user - будет вызвана уже с инициализированным рантаймом. Для работы в IDE данная функция не подойдет, потому что в IDE все работает в главном потоке. Для отладки в IDE используется функция InitCurrentThreadAndCallFunctionIDEProc которая возвращает адрес ассемблерного переходника который транслирует вызов в главный поток и вызовет пользовательскую функцию в контексте главного потока. Данная функция принимает адрес пользовательской callback-функции и размер параметров в байтах. В качестве параметра пользовательской функции она всегда передает адрес первого параметра. Немного расскажу о работе этого механизма в IDE. Для трансляции вызова из вызывающего потока в главный поток используется message-only окно. Данное окно создается посредством вызова функции InitializeMessageWindow. При первом вызове создается WindowProc процедура со следующим кодом: ![]() ![]() CMP DWORD [ESP+8], WM_ONCALLBACK JE SHORT L JMP DefWindowProcW L: PUSH DWORD PTR SS:[ESP+10] CALL DWORD PTR SS:[ESP+10] RETN 10 Как видно из кода данная процедура "слушает" сообщение WM_ONCALLBACK которое содержит в параметре wParam - адрес функции, а в параметре lParam параметры. При получении этого сообщение она вызывает данную процедуру с данным параметром, остальные сообщения игнорируются. Данное сообщение отправляется как-раз ассемблерным переходником из caller-потока. Далее создается окно и хендл этого окна и хендл кучи сохраняются в данных класса окна. Это используется для устранения утечки памяти в IDE, т.к. если класс один раз зарегистрирован то потом данные параметры можно получить в любой сессии отладки. Сама callback-функция генерируется в InitCurrentThreadAndCallFunctionIDEProc, но сначала проверяется не была ли уже создана подобная процедура (чтобы не создавать одинаковые переходники). Сам переходник имеет следющий код: ![]() ![]() LEA EAX, [ESP+4] PUSH EAX PUSH pfnCallback PUSH WM_ONCALLBACK PUSH hMsgWindow Call SendMessageW RETN lParametersSize Как видно из ода, что при вызове callback-функции вызов транслируется через SendMessage в главный поток. Параметр lParametersSize используется для правильного восстановления стека. Следующая особенность модуля - это создание объектов в отдельном потоке причем создавать можно как приватные объекты (для этого используется метод основанный на коде модуля NameBasedObjectFactory by firehacker). Для создания проектных классов используется функция CreatePrivateObjectByNameInNewThread для ActiveX-публичных классов CreateActiveXObjectInNewThread и CreateActiveXObjectInNewThread2. Прежде чем создавать экземпляры проектных классов нужно сначала разрешить маршалинг данных объектов посредством вызова функции EnablePrivateMarshaling. Данные функции принимают идентификатор класса (ProgID/CLSID для ActiveX и имя для проектных классов), идентификатор интерфейса (по умолчанию используется IDispatch/Object). При успешном вызове функции возвращают отмаршаленый объект и ID асинхронного вызова. Для скомпилированного варианта это ID потока для IDE - указатель на объект. Объекты создаются и "живут" в функции ActiveXThreadProc. Жизнь объектов контролируется через счетчик ссылок (когда он равен 1 значит только ActiveXThreadProc ссылается на объект и можно его удалять и завершать поток. Вызывать методы можно синхронно - просто вызывать метод как обычно, либо асинхронно - используя процедуру AsynchDispMethodCall. Данная процедура принимает ID асинхронного вызова, имя метода, тип вызова, объект который получит уведомление о вызове, имя метода уведомления и список параметров. Процедура копирует параметры во временную область, маршалит объект уведомления и отправляет данные потоку объекта через WM_ASYNCH_CALL. Стоит отметить что здесь не поддерживается маршалинг параметров, поэтому следует с осторожностью передавать ссылки на объекты. Если нужно отмаршалить объектную ссылку то следует использовать синхронный метод для маршалинга объектов и далее вызвать асинхронный метод. Процедура возвращается немедленно. В потоке ActiveXThreadProc данные извлекаются и выполняется синхронный вызов посредством MakeAsynchCall. Тут все просто, вызывается CallByName для объекта потока и CallByName для уведомления. Метод уведомления имеет следующий прототип: ![]() ![]() Public Sub CallBack(ByVal vRet As Variant) Следующие функции предназначены для маршалинга: Marshal, Marshal2, UnMarshal, FreeMarshalData. Первая создает информацию о маршалинге (Proxy) интерфейса и заносит ее в поток который возвращает. Принимает в параметре pInterface идентификатор интерфейса (по умолчанию IDispatch/Object). Функция UnMarshal наоборот принимает поток и на основе информации создает Proxy-объект. Опционально можно освободить объект потока. Marshal2 делает тоже самое что и Marshal за исключением того что она позволяет создавать Proxy-объект множество раз в разных потоках. FreeMarshalData соответственно освобождает данные и поток. Если к примеру требуется перенести ссылку на объект между двумя потоками то достаточно вызвать пару Marshal/UnMarshal соответственно в потоке создавшем объект и потоке принимающем ссылку. В другом случае если к примеру есть один глобальный объект и нужно передать ссылку на него во множество потоков (к примеру объект логирования) то в потоке объекта вызывается Marshal2, а в клиентских потоках вызывается UnMarshal с параметром bReleaseStream равным False. Когда данные больше не нужны вызывается FreeMarshalData. Функция WaitForObjectThreadCompletion предназначена для ожидания завершения объектного потока и принимает ID асинхронного вызова. Эту функцию желательно вызывать всегда при завершении основного процесса, поскольку объектный поток так или иначе может взаимодействовать с основным потоком и его объектами (к примеру если объектный поток имеет маршаленую ссылку на интерфейс основного потока). Функция SuspendResume предназначена для приостановления/возобновления объектного потока. bSuspend определяет усыпить либо возобновить поток. Помимо модуля также в архиве есть несколько примеров работы с ним: Проект на GitHub. Модуль слабо тестировался, поэтому возможны баги. Буду очень рад любым замечаниям, по мере возможности буду их исправлять. Всем спасибо за внимание! |
Сообщ.
#2
,
|
|
|
Обновление.
Пофикшены некоторые баги, удален неиспользуемый код, добавлены примеры. Проект переехал на GitHub. |
Сообщ.
#3
,
Сообщение отклонено: B.V. -
|
Сообщ.
#4
,
Сообщение отклонено: B.V. -
|