callback вызывается из произвольного потока

[sosed213]

FLS колбеки вызываются.
Где именно происходит зависание, сложно сказать, т.к. такое бывает только в скомпилированном файле. Т.е. Форма закрывается, а процесс висит.
Возможно в Form_Unload при вызове Abort, висит на WaitForObjectThreadCompletion m_lAsyncID.

Про постоянную инициализацию/деинициализация COM я кажется понял, это происходит в WIMMessageCallback при вызове InitCurrentThreadAndCallFunction?

[Хакер]

FLS колбеки вызываются.
Где именно происходит зависание, сложно сказать, т.к. такое бывает только в скомпилированном файле. Т.е. Форма закрывается, а процесс висит.
Возможно в Form_Unload при вызове Abort, висит на WaitForObjectThreadCompletion m_lAsyncID.

Возьми OllyDbg, присоединись к зависшему процессу и посмотри, сколько внутри потоков и что они делают, где крутятся или на чём спаят.
Можно, в качестве «варианта для нищих» взять Process Explorer, хоя он не так информативен.

procexp-threads.png (22.64 Кб) Просмотров: 3914

Наличие отладочных категорически желательно в обоих вариантах.

[The trick]

Возможно в Form_Unload при вызове Abort

Поставь MsgBox - выясни в каком месте именно зависает. Я пока тоже подумаю. Можешь еще дамп скинуть сюда, я посмотрю.

[sosed213]

Пока больше не зависает. Возможно это был результат моих экспериментов. Но если повторится сделаю дамп.

Прежде чем дальше развивать возможности WIMGAPI.DLL, хочется довести до ума многопоточность.
Все думаю как избежать постоянной инициализации/деинициализации COM.
И тут есть вопрос. Можно ли было в модуле modMultiThreading использовать вместо TLS-слота, FLS-слот. Вроде как FLS даже лучше. Так же как и в примере указать FlsCallback, где и проводить деинициализацию COM автоматически при завершении потока. А в функциях InitCurrentThreadAndCallFunction и ThreadProc, один раз инициализировать COM? Так вроде меньше накладных расходов.

[The trick]

Все думаю как избежать постоянной инициализации/деинициализации COM.

Я же написал. Точно также как делается сейчас, но вызывать CoInitialize при первом колбеке, а не при первом выводе в лог. Вызов CoInitialize при уже инициализированном апартменте ничего не делает только увеличивает счиетчик - это почти никак не сказывается на производительности.

Можно ли было в модуле modMultiThreading использовать вместо TLS-слота, FLS-слот. Вроде как FLS даже лучше.

FLS слоты не работают на XP. Мой модуль поддерживает работу на этой системе. Если хочешь, можешь переделать сам модуль, но в этом случае просто можешь в InitCurerntThreadAndCallFunction не вызывать CoUninitialize - и проблема решится.

[sosed213]

Продолжаю разбираться, и появляются новые вопросы.

Во время применения wim-образа, я могу из кода формы обращаться к классу m_cWimImage (чтение свойств, выполнение методов)?

Если сейчас я просто напишу:

Код: Выделить всё

Private Sub Command1_Click()
    Me.Caption = m_cWimImage.ApplyPath
End Sub


То происходит зависание. Я так понимаю, что из основного потока я пытаюсь залезть в другой поток. Т.е. как то надо использовать маршалинг?
Или например, есть API функция Public Declare Function WIMGetMessageCallbackCount Lib "WIMGAPI.DLL" (ByVal hWIM As Long) As Long, если я её захочу её вызвать, нужен будет hWIM, можно было бы прочитать значение m_cWimImage.GethWim.
И при этом опять зависает, видимо по той-же причине.

[The trick]

Во время применения wim-образа, я могу из кода формы обращаться к классу m_cWimImage (чтение свойств, выполнение методов)?

Нет. Поскольку поток занят, вызов будет ожидать пока поток не освободится. А вообще обращаться к m_cWimImage можно (к примеру как можешь видеть в процедуре cmdApply_Click), т.к. ссылка уже отмаршалена.
Просто во время применения образа поток в котором живет экземпляр СWimImage висит исполняя код WIMApplyImage (поскольку функция вызвана в этом же потоке). И обращения из других потоков (в том числе и главного) ждут пока метод завершится. Но логику работы можно изменить так как нужно и к примеру объект СWimImage можно создавать в главном потоке, а логика внутри класса будет уже создавать поток который вызывает WIMApplyImage, в этом случае свойства и методы можно будет вызывать без проблем. Просто для упрощения я так не делал.

То происходит зависание. Я так понимаю, что из основного потока я пытаюсь залезть в другой поток. Т.е. как то надо использовать маршалинг?

Мне кажется ты не совсем понимаешь что такое маршалинг. Ссылка m_cWimImage уже отмаршалена, поэтому никакой дополнительный маршалинг не нужен.

Или например, есть API функция Public Declare Function WIMGetMessageCallbackCount Lib "WIMGAPI.DLL" (ByVal hWIM As Long) As Long, если я её захочу её вызвать, нужен будет hWIM, можно было бы прочитать значение m_cWimImage.GethWim.

Ну во-первых, нужно по документации посмотреть, можно ли hWIM передавать между потоками. Во-вторых, hWim в данной реализации необходимо получать перед вызовом Apply, но опять ты можешь переделать логику как хочешь.

[The trick]

Добавлю также что можно еще создать MTA объект, к нему можно обращаться из любых потоков, но все придется делать вручную (виртуальную таблицу, синхронизацию и т.п.)

[sosed213]

Буду пробовать создавать СWimImage в главном потоке.

[The trick]

Буду пробовать создавать СWimImage в главном потоке.

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

[sosed213]

Когда использую функцию vbCreateThread, как определить что поток завершился? Пробовал через WaitForObjectThreadCompletion, но событие не наступает.

Код: Выделить всё

gHandles = vbCreateThread(0, 0, AddressOf ThreadProc, VarPtr(mtThreadsData), 0, 0)
WaitForObjectThreadCompletion gHandles


Код: Выделить всё

Public Function ThreadProc( _
                 ByRef tData As tThreadData) As Long
    If WIMApplyImage(tData.hImage, tData.lpszPath, tData.dzApplyFlags) = 0 Then
        tErrNumber = 0: tErrDescrt = "": tErrNumber = Err.LastDllError: tErrDescrt = ErrMessageText(tErrNumber)

        PutLog "WIMApplyImage failed " & tErrNumber & "  " & tErrDescrt
        Err.Raise tErrNumber, "Apply-WIMApplyImage", tErrDescrt

    End If
End Function

[The trick]

Когда использую функцию vbCreateThread, как определить что поток завершился? Пробовал через WaitForObjectThreadCompletion, но событие не наступает.

Код: Выделить всё

gHandles = vbCreateThread(0, 0, AddressOf ThreadProc, VarPtr(mtThreadsData), 0, 0)
WaitForObjectThreadCompletion gHandles


Код: Выделить всё

Public Function ThreadProc( _
                 ByRef tData As tThreadData) As Long
    If WIMApplyImage(tData.hImage, tData.lpszPath, tData.dzApplyFlags) = 0 Then
        tErrNumber = 0: tErrDescrt = "": tErrNumber = Err.LastDllError: tErrDescrt = ErrMessageText(tErrNumber)

        PutLog "WIMApplyImage failed " & tErrNumber & "  " & tErrDescrt
        Err.Raise tErrNumber, "Apply-WIMApplyImage", tErrDescrt

    End If
End Function

WaitForObjectThreadCompletion не подходит, т.к. она принимает lAsyncID. vbCreateThread, являясь аналогом CreateThread, возвращает HANDLE который нужно передавать в API функцию WaitForSingleObject.

[sosed213]

Если использовать WaitForSingleObject, то форма зависает до завершения применения файла. Я это пробовал сразу.

[The trick]

Если использовать WaitForSingleObject, то форма зависает до завершения применения файла. Я это пробовал сразу.

Ну а что ты ожидаешь? Эта функция усыпляет поток пока либо объект не перейдет в сигнальное состояние, либо не пройдет таймаут.

[sosed213]

Сложная штука - потоки. Я совсем запутался.
Получается что нельзя чтобы было удобно и чтобы при этом работало?

[The trick]

Сложная штука - потоки. Я совсем запутался.
Получается что нельзя чтобы было удобно и чтобы при этом работало?

Я не понимаю что ты хочешь. Скажи какой функционал должен быть. Класс должен генерировать события периодически, или как?
Кстати тут в кирпичах я выкладывал класс который может асинхронно ожидать объекты ядра и генерировать события.

[sosed213]

Я хочу реализовать полноценное использование библиотеки wingapi, для дальнейшего использования. Хочу чтобы работа с классом была гибкой. В частности чтобы во время выполнении длительной операции (применении, захвата, монтирования образа), не было зависания формы, был рабочий колбек, и была возможность взаимодействия с классом.

The trick, твой крайний пример, это лучшее на что я мог бы рассчитывать. Спасибо тебе большое!

[The trick]

Я хочу реализовать полноценное использование библиотеки wingapi, для дальнейшего использования. Хочу чтобы работа с классом была гибкой. В частности чтобы во время выполнении длительной операции (применении, захвата, монтирования образа), не было зависания формы, был рабочий колбек, и была возможность взаимодействия с классом.

The trick, твой крайний пример, это лучшее на что я мог бы рассчитывать. Спасибо тебе большое!

Просто создай дополнительный класс в котором будет логика работы с потоком, а класс CWIMImage будет как у тебя сейчас форма - принимать колбеки (как сейчас вызывается процедура LogEntry/Applied). Это самый простой путь - ты сможешь работать с классом даже когда операция выполняется, только нужно будет следить когда операция выполняется и генерировать ошибку типа E_PENDING.
Другой путь - выполнять операцию монтирования в отдельном потоке, класс CWIMImage также в главном потоке. В классе CWIMImage создать Message-Only окно которое будет принимать сообщения из колбеков WIMMessageCallback2, соответственно главный поток получая сообщение "дергает" событие у класса, чекает аборт. Тут также стоит следить пока выполняется операция чтобы генерировать ошибки при повторном ApplyImage/Let TempPath и т.д., т.е. данные которые уже установлены и их нельзя изменять пока идет применение образа.
Еще есть путь - писать ограниченный код, тогда никакого модуля не нужно вообще, но придется заюзать библиотеку функций.
Также можно еще написать MTA объект, но также нужно писать ограниченый код, который сможет принимать колбеки из разных потоков без маршалинга. В этом случае также можно обойтись без модуля. Вот к примеру. В этом примере также вызов методов объекта ISampleGrabberCB происходит из разных потоков.

[sosed213]

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

Поэтому буду двигаться горизонтально, в рамках бесценного, для меня, примера от The trick, используя поочерёдный вызов функций.

Спасибо за помощь и участие!

[sosed213]

Все таки решил попробовать создать дополнительный класс который будет работать в отдельном потоке. И вроде бы даже работает, но не уверен что правильно организовал логику работы с потоком. И бывает после применения wim-образа и закрытии формы, процесс остается висеть. При помощи Process Explorer посмотрел что происходит в момент зависания (скрины прикладываю).
Большая просьба к The trick, если есть возможность глянуть код, что сделал не правильно.

[The trick]

Тут ошибка в методе Applied.
Смотри.
Ты создаешь класс CWIMImageThead в новом потоке. Далее ты асинхронно вызываешь метод Apply, а в качестве уведомления о завершении вызываешь метод Applied. Тут все гуд. Но вот смотри, когда у тебя успешно совершен вызов Apply, и вызывается метод-колбек Applied, то ты в нем вызываешь Abort и CloseAll - это неправильно, поскольку ты создаешь deadlock посредством вызова WaitForObjectThreadCompletion m_lAsyncID в методе Abort. У тебя вызов из дочернего потока ожидает завершения Applied, а ты в свою очередь запускаешь ожидание дочернего потока - получается оба потока ждут друг-друга.
Измени эту логику, и приложение не будет висеть.

[sosed213]

Т.е. в методе-колбек Applied, нужно убрать Abort, а CloseAll оставить?

А вообще хорошо бы перед вызовом WaitForObjectThreadCompletion m_lAsyncID, проверять существует ли еще асинхронный вызов, по m_lAsyncID. Есть такая возможность?

И вопрос по обработке ошибок.
Если в классе CWIMImageThead, в методе Apply возникнет ошибка, как ее обработать? Т.е. как ее переправить в какую нибудь процедуру (похожую на Applied), чтобы потом с ней работать? В PutLog ошибку видно.
Или можно сделать такую же функцию как PutLog, но для ошибок?

[The trick]

Т.е. в методе-колбек Applied, нужно убрать Abort, а CloseAll оставить?

Можно и так.

А вообще хорошо бы перед вызовом WaitForObjectThreadCompletion m_lAsyncID, проверять существует ли еще асинхронный вызов, по m_lAsyncID. Есть такая возможность?

Вообще ASyncID - это ID потока. Можешь попробовать открыть его и получить хендл, см. код функции WaitForObjectThreadCompletion. Но если поток был закончен то ничего не выйдет. Также не выйдет если поток был завершен, а в системе за это время появился другой поток с тем же ID. Обычно функции ожидания вызываются когда поток еще исполняется, поэтому нет необходимости узнавать если поток еще исполняется и если нет то вызывать ожидание. Поскольку пока код проверки выполняется поток вполне может изменить состояние.

И вопрос по обработке ошибок.
Если в классе CWIMImageThead, в методе Apply возникнет ошибка, как ее обработать? Т.е. как ее переправить в какую нибудь процедуру (похожую на Applied), чтобы потом с ней работать? В PutLog ошибку видно.
Или можно сделать такую же функцию как PutLog, но для ошибок?

Можно многими способами сделать, можно Sub Apply переделать в функцию и через возвращаемое значение смотреть (оно пойдет в Applied, параметр vRet). Можно какой-либо колбек объект сделать для этого. Смотри примеры использования модуля на гитхабе, там много примеров есть.

[sosed213]

можно Sub Apply переделать в функцию и через возвращаемое значение смотреть (оно пойдет в Applied, параметр vRet).

Это я сдела.
Но Applied срабатывает только в случае успешного выполнения функции WIMApplyImage.

В случае генерации ошибки (например закончилось место на диске или установить флаг m_bAbort), метод Applied не наступает.


P.S. вопрос не по теме. Не могу найти как подписаться на тему. Раньше вроде было.

[The trick]

можно Sub Apply переделать в функцию и через возвращаемое значение смотреть (оно пойдет в Applied, параметр vRet).

Это я сдела.
Но Applied срабатывает только в случае успешного выполнения функции WIMApplyImage.

В случае генерации ошибки (например закончилось место на диске или установить флаг m_bAbort), метод Applied не наступает.

Ну ты сделай так чтобы вызывался. У тебя этот код:

Код: Выделить всё

    If WIMApplyImage(m_hCurImage, StrPtr(m_sApplyPath), WIM_FLAG_VERIFY Or WIM_FLAG_NO_RP_FIX Or WIM_FLAG_NO_DIRACL Or WIM_FLAG_NO_FILEACL) = 0 Then
        tErrNumber = 0: tErrDescrt = "": tErrNumber = Err.LastDllError: tErrDescrt = ErrMessageText(tErrNumber)
       
        PutLog "WIMApplyImage(2) failed " & tErrNumber & "  " & tErrDescrt
        Err.Raise tErrNumber, "Apply-WIMApplyImage", tErrDescrt
       
    End If

Генерирует ошибку. Просто не генерируй, а возвращай через Function.

[sosed213]

Так просто, убрал Err.Raise и сработало!

[sosed213]

Заметил, что после успешного применения образа или прерывания применения образа, и закрытии формы, процесс завершается, но следом появляется процесс WerFault.exe (скрин прикладываю).
Не могу понять что упускаю. Вроде и колбеки все отключаю, и хендлы все закрываю.

[The trick]

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

Ты вызываешь UninitLog 2 раза.

[sosed213]

В очередной раз Спасибо!

[sosed213]

Сегодня создал запрос в Касперский, по поводу ложного срабатывания на модуль modMultiThreading2.bas.

В ответе они это подтвердили, и сказали что "Это было ошибочное срабатывание. Оно будет исправлено."

Вот