Многопоточное сохранение файлов с оповещением

[jangle]

Возникла непростая для меня задача. Необходимо реализовать фоновое сохранение документов большого объема 20-80 мбайт в сетевую папку.
Допустим есть 10 программ-клиентов, в каждой прописан путь к одной определенной папке на сервере. Закончив подготовку документа пользователь жмет кнопочку Save, после чего документ должен начать сохранятся в другом потоке, чтобы интерфейс программы не зависал. Ведь сохранение по-локальной сети может занять довольно продолжительное время. После того как документ сохранится должно прийти событие в основной поток приложения, что документ сохранен. Затем все остальные программы-клиенты, которые активны в данный момент, должны получить сообщение/событие, что в сетевую папку сохранились некие файлы. В общем задача многопоточное сохранение файлов с оповещением всех клиентов которые "наблюдают" за данной сетевой папкой. Если есть примеры подобного кода, поделитесь пожалуйста или инфой по данному вопросу.

P.S. И еще желательно чтобы многопоточность не приводила к крашам во время отладки в IDE, поскольку проект сложный, повесится можно без нормальной отладки.

[Antonariy]

Закончив подготовку документа пользователь жмет кнопочку Save, после чего документ должен начать сохранятся в другом потоке, чтобы интерфейс программы не зависал.
...
И еще желательно чтобы многопоточность не приводила к крашам во время отладки в IDE, поскольку проект сложный, повесится можно без нормальной отладки.

Раз плюнуть

Затем все остальные программы-клиенты, которые активны в данный момент, должны получить сообщение/событие, что в сетевую папку сохранились некие файлы.

Два плюнуть

Правильность выбора раздела вызывает сомнения

[jangle]

Что-то мне не нравится вариант с ActiveX EXE, в VB6 это единственный путь?

[Antonariy]

Что-то мне не нравится вариант с ActiveX EXE

Это ничем не обоснованные эмоции.

в VB6 это единственный путь?

Да.

[jangle]

Вторая ссылка это что? Там какие-то примеры работы с Audio

[jangle]

[Да.

А что если использовать Native DLL из которой создавать отдельный тред, в котором сохранять файл, а после записи файлв вызывать бейсик-CallBack функцию для оповещения о событии конца записи. Это вроде проще должно быть чем ActiveX EXE

[Antonariy]

Вторая ссылка это что? Там какие-то примеры работы с Audio

Там примеры реализации броадкаста. Смотри примеры мессенджеров.

А что если использовать Native DLL из которой создавать отдельный тред, в котором сохранять файл, а после записи файлв вызывать бейсик-CallBack функцию для оповещения о событии конца записи. Это вроде проще должно быть чем ActiveX EXE

Ну если ты считаешь, что это проще...

Проще только создать отдельную activex exe, которая будет заниматься лишь сохранением. Но это будет уже отдельный процесс, а не поток.

[jangle]

Проще только создать отдельную activex exe, которая будет заниматься лишь сохранением. Но это будет уже отдельный процесс, а не поток.

Есть примеры? Не могу найти толковых статей про ActiveX EXE.
И еще вопрос возник, допустим Клиент-1 читает из общей папки файл документа размером в 50 мбайт.
Открывает его на чтение, и фигачит себе в память. В этот момент Клиент-2 пытается открыть на редактирование файл этого документа.
А Клиент-3 пытается прочитать файл который загружает Клиент-1 и пытается открыть на редактирование Клиент-2.
Ситуация крашовая?

[Хакер]

в VB6 это единственный путь?

Да.

Нет.

Что-то мне не нравится вариант с ActiveX EXE

Это ничем не обоснованные эмоции.

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

Многопоточность в VB можно поюзать (в контексте этого абзаца, само собой разумеется, не используя мой ещё не выпущенный кирпич) просто создав пару Standard EXE + ActiveX DLL.
Standard EXE создаёт новый поток (CreateThread), из нового потока специальный код делает CoCreateInstance и создаёт экземпляр класса из ActiveX DLL. Каждый такой «объект» будет жить в своём апартаменте, а значит в своём потоке.

В отличие от аналогичного с ActiveX EXE, здесь нужен «специальный код» (если CoCreateInstance вызывается VB-кодом, если же для этого используется крохотный переходник на любом другом языке, то и специальный код не нужен), но главное (и ключевое!) отличие в том, что всё выполняется в рамках одного адресного пространства.

[Хакер]

И я напоминаю, что когда идёт исходящий RPC-вызов из одного STA-апартамента в другой STA-апартамент, выполнение в первом, говоря грубо, блокируется.

Так что если нужно сделать, чтобы три однотипных задачи выполнялись в разных потоках одновременно, и например, задача занимает 10 минут, то сделать так не получится:

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

Dim A As IThreadWorker, B As IThreadWorker, C As IThreadWorker

Set A = New CThreadWorkerFromActivexExe
Set B = New CThreadWorkerFromActivexExe
Set C = New CThreadWorkerFromActivexExe

A.DoAction
B.DoAction
C.DoAction

то задачи не будут работать одновременно, а выполнение этого кода займёт 30 минут, а не 10.

И если использовать не ActiveX EXE, а ActiveX DLL, то тоже не будет.

Придётся вручную реализовывать асинхронную модель: метод из DoAction переименовывать в ScheduleAction с измененем контента: реализация метода уже не выполняет саму задачу, а вместо этого шлёт своему окну специальное сообщение и сразу же возвращает выполнение. А вот уже обработчик сообщений окна получив это сообщение сам выполняет задачу. И опционально по завершению выполнения работы рейсит событие OnCompletion.

К слову, в моём кирпиче такой проблемы нет: функция CreateBasicThread работает так же, как CreateThread, и не ждёт, пока ThreadProc в новом потоке возвратит выполнение, а возвращает выполнение в вызывающем потоке сразу же.

[Antonariy]

Есть примеры?

Первая ссылка чем не пример? Статей никогда не видел, да там и писать собственно не о чем.

Ситуация крашовая?

Нет, если обрабатывать ошибки. При чтении нужно ставить соответствующую блокировку, чтобы кто-то не попытался в это время записать.

Это как раз хорошо обсновованная позиция.

Тобой, но не им.

Я не знаю, откуда взялась эта тупая идиотия, но ходит убеждение, что ActiveX-EXE способны дать вам многопоточность, а ActiveX-DLL — не способны, поэтому практически никогда не рассматриваются.

Вопрос в количестве гемороя и "специального кода", который кроме тебя никто не писал. В моем примере всего один многопоточный exe и ни капли соков мозга.

[Хакер]

Тобой, но не им.

А зачем?
Создатель потока и создаваемый поток оказываются в разных процессах. Это не многопоточность. Единственная возможность передавать данные между двумя апартаментами в этом случае: маршаллинг при объектных вызовах. Это достаточно неэффективно. И вторая причина в том, что объектные вызова между апартаментами в рядовом случае являются синхронными, то есть блокирующими, и никакого эффекта от многопоточности нет. Пока доп. поток работает, основной поток не работает, а ждёт, когда отработает дополнительный. И пока ждёт, не может создать ещё один дополнительный. В чём профит?

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

Ну, достаточно вызвать CoCreateInstance. Если объявить её в TLB, и на VB никакого как такового специального кода не нужно.

[Хакер]

А если подумать, можно и без TLB, обычным Declare Function, используя подход с «предварительной разведкой».

[Antonariy]

Ты пример с первой ссылки скачивал вообще, запускал? Что там блокируется?
Там один процесс создает 10 потоков, которые, выполняя sleep, не мешают ни друг другу ни основному потоку — интерфейс отзывается на действия пользователя.

[Хакер]

Ты пример с первой ссылки скачивал вообще, запускал? Что там блокируется?

Не смотрел. Скачал. Посмотрел.

А ты читал, что я писал, что чтобы ничего не блокировалось, метод класса должен не сам выполнять работу, а слать сообщение окну, и вот уже обработчик оконных сообщений получив сообщение должен выполнять работу — тогда ничего не блокируется?

Именно этот случай в исходнике: метод SetJob сам не выполняет работу (Sleep), а отсылает окну сообщение (WM_TIMER) и уже обработчик сообщения (WM_TIMER → событие Timer) выполняет полезную нагрузку?

______

И да, здесь ActiveX-сервер создаёт объект из самого себя, поэтому оба апартамента оказываются в одном процессе, и в этом плане тоже нет проблемы. Но всё равно, это большой Overkill

[Хакер]

А теперь о проблемах такого подхода:

• Чтобы поместить объект в ROT, нужно быть админом. Я работаю под огр. учёткой, и получаю «Unexpected error. Quiting.» при запуске. Это главная проблема.
• Если запустить два инстанса процесса, то у первого новый потоки будут создаваться в нём же (получается общее АП), а у второго новые потоки будут создаваться в первом (и общего АП не будет). Предсказать заранее, в каком процессе будет рождён новый поток нельзя, а значит и полагаться на то, что поток-родитель и поток-порождённый имеют общее АП тоже нельзя. А значит всё то, что я писал выше, опять таки актуально.

[jangle]

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

[Хакер]

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

P.S. jangle, а ты пробовал использовать Overlapped IO? Может и не нужна многопоточность?

[Antonariy]

Именно этот случай в исходнике

А, ну да, я уже забыл про это. Блокировка SetJob была очевидна, пришло в голову только создать новое окно с таймером. А overkill в чем? В лишнем окне?

Чтобы поместить объект в ROT, нужно быть админом.

Это не большая проблема, просто этот кусок кода у меня кочует по проектам. Однажды был нужен GetObject, а в этом примере наверное достаточно App.PrevInstance.

Если запустить два инстанса процесса, то у первого новый потоки будут создаваться в нём же (получается общее АП), а у второго новые потоки будут создаваться в первом (и общего АП не будет).

GetObject решал и эту проблему, при наличии первого инстанса второй просто молча выйдет. А вызову CreateObject для создания потока холостой проход Sub Main никак не мешает.

[jangle]

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

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

P.S. jangle, а ты пробовал использовать Overlapped IO? Может и не нужна многопоточность?

Нет не пробовал. Попробую изучить эту тему. Мне в принципе многопоточность не нужна, главное найти способ чтобы пользователь мог продолжить работу с программой после нажатия кнопки сохранения данных, а не ждать 30-40 секунд пока данные запишутся на диск.

[Хакер]

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

Ну это самое простое решение, я бы тоже так сделал, но достаточно посылки сообщения. Здесь дело в асинхронной природе сообщений.

А overkill в чем? В лишнем окне?

В использовании OLE-шных механизмов. ROT, моникеры, маршаллинг, связывание. Всё-так многзадачность — это базавая фича процессора, выполненная «на уровне транзисторов». А тут такие гигантские прибамбасы ради того, чтобы получить новый поток.

Это не большая проблема, просто этот кусок кода у меня кочует по проектам. Однажды был нужен GetObject, а в этом примере наверное достаточно App.PrevInstance.

Это большая проблема, потому что GetObject используется не для того, для чего App.PrevInstance, а для того, чтобы создать из самого себя объект в новом апартаменте. Ключевой момент здесь в таблице работающий объектов (ROT).

GetObject решал и эту проблему, при наличии первого инстанса второй просто молча выйдет. А вызову CreateObject для создания потока холостой проход Sub Main никак не мешает.

Не решает. Что если нам нужен 3 процесса по 4 потока в каждом?

[Antonariy]

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

Лучше overkill компьютера, чем разработчика Компьютерное время стоит дешевле, а пользователь лишних тактов процессора не почувствует. Эти прибамбасы вредны лишь если потоки создаются и умирают постоянно, а не от случая к случаю.

Это большая проблема

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

Что если нам нужен 3 процесса по 4 потока в каждом?

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

[Хакер]

Лучше overkill компьютера, чем разработчика Компьютерное время стоит дешевле.

Компьютерное время тратится миллион раз, время разработчика — один раз. FireFox для закрытия одной вкладки требует N миллисекунд, но для закрытия 100 вкладок — не 100N, а (похоже) факториал от N. Кривой медленный софт уже невероятно достал.

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

Ты не понял или я не понял? Помещение в ROT здесь играет ключевую роль, от него нельзя избавиться. Так что проблема остаётся.

А если нужно приложение реального времени, то WinXP проблема.

Не понял, причём тут приложения реального времени? Я хочу открыть 5 блокнотов. Будет 5 инстансов notepad.exe. Причём тут реальное время? 5 инстансов какого-то процесса — это экзотические условия?

[Antonariy]

Ты не понял или я не понял? Помещение в ROT здесь играет ключевую роль, от него нельзя избавиться. Так что проблема остаётся.

Проверил, PrevInstace не работает, но это не значит, что нельзя избавиться от ROT. Из головы вылетело как это называется: создать через API глобальный системный хендл и проверять его наличие. Или порт открыть, если брандмауэр позволит.

5 инстансов какого-то процесса — это экзотические условия?

5 инстансов приложения Jangle — вот экзотические условия.

[Хакер]

Проверил, PrevInstace не работает, но это не значит, что нельзя избавиться от ROT. Из головы вылетело как это называется: создать через API глобальный системный хендл и проверять его наличие. Или порт открыть, если брандмауэр позволит.

Это называется мутекс.
Блин, причём тут это. PrevInstance и подход с мутексом используются для того, чтобы определить, этот инстанс — единственный, или уже запущен один или более.

GetObject в твоём коде нужен не для этого.

[jangle]

P.S. jangle, а ты пробовал использовать Overlapped IO? Может и не нужна многопоточность?

Так и не смог нагуглить ни одного примера использования Overlapped IO в VB6

[NashRus]

Чтобы поместить объект в ROT, нужно быть админом. Я работаю под огр. учёткой, и получаю «Unexpected error. Quiting.» при запуске. Это главная проблема.

Не знаю, как насчет админа и ROT. Скорее всего это не так, иначе бы весь VBA и интеграция приложений не работали у офисных пользователей в офисе.

А вот сообщение «Unexpected error. Quiting.» появляется из-за того, что COM-EXE не может себя зарегистрировать в HKLM при первом запуске (если его нет в HKCR) и вываливает это сообщение. А вот если COM-EXE есть хотя бы в HKCU, то всё работает: exe запускается, объекты создаются и данное сообщение не показывается.

То, что это главная проблема, я очень согласен. Я даже на форуме в свое время как-то этот вопрос поднимал, как и что запатчить, чтобы COM-EXE регился в HKCU, а не в HKLM. Без этого необходим либо ланчер, либо инсталлер.

Так и не смог нагуглить ни одного примера использования Overlapped IO в VB6

Это есть, например, в примерах к книге "Дан Эпплман - Win32 API и Visual Basic для профессионалов".
Там это используется для работы с COM-портами. Пример там достаточно мутный.

[Antonariy]

GetObject в твоём коде нужен не для этого.

GetObject в моем коде вообще не нужен. А использовал я его именно для проверки наличия предыдущего инстанса.

Не знаю, как насчет админа и ROT. Скорее всего это не так, иначе бы весь VBA и интеграция приложений не работали у офисных пользователей в офисе.

Существует утилита ROTView (точность названия не гарантирую), мое приложение она видела, офис — нет. Либо офис не использует ROT, либо как-то прячется.

[jangle]

Продолжаю изучать вопрос фонового сохранения файла. Вот пример PB DLL которую вызываю из VB проекта.
В функцию SaveFileThread передаю имя файла, его содержимое, и указатель на CallBack функцию в VB коде.
Данные нормально сохраняются, основной поток не блокируется, но происходит краш при выходе из mThread_Save.
Подозреваю что ошибка в чем-то элементарном? VB пример в аттаче

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

#Compile DLL
#Dim All
#Include Once "Win32API.inc"

Global ghInstance As Dword
Global hThread As Dword
Global gFileName      As String
Global gFileContent   As String
Global gCallBackFunct As Dword
Declare Function SaveFileThread Alias "SaveFileThread" (ByVal FileName As String, ByVal FileContent As String, ByVal CallBackFunct As Dword) As Dword
Declare Thread Function mThread_Save(ByVal mWnd As Dword) As Dword
Declare Sub CallBackProc()

'-------------------------------------------------------------------------------
' Main DLL entry point called by Windows...
'
Function LibMain (ByVal hInstance   As Long, _
                  ByVal fwdReason   As Long, _
                  ByVal lpvReserved As Long) As Long
  Select Case fwdReason
    Case %DLL_PROCESS_ATTACH
        ghInstance = hInstance
        Function = 1   'success!
    Case %DLL_PROCESS_DETACH
        Function = 1   'success!
    Case %DLL_THREAD_ATTACH
        Function = 1   'success!
    Case %DLL_THREAD_DETACH
        Function = 1   'success!
    End Select
End Function
'-------------------------------------------------------------------------------

Thread Function mThread_Save(ByVal mWnd As Dword) As Dword
    Local lResult As Dword
    Local f As Dword
    f=FreeFile
    Open gFileName For Binary  As f
     Put$ f,gFileContent
    Close f
    gFileContent=""
    Thread Close hThread To lResult
    Call Dword gCallBackFunct Using  CallBackProc 'Вызов функции в VB коде для оповещении о конце записи файла
End Function

Function SaveFileThread Alias "SaveFileThread" (ByVal FileName As String, ByVal FileContent As String, ByVal CallBackFunct As Dword) Export As Dword
    gFileName=FileName
    gFileContent=FileContent
    gCallBackFunct=CallBackFunct
    Thread Create mThread_Save(0) To hThread
    FileContent=""
End Function

[Хакер]

В чём смысл демонстративного игнорирования необходимости инициализировать контекст для выполнения в нём VB-функции?