DLL, потоки

[B_N]

Сообщение от BOBAH13

Вообщем вот накалякал... знаете вроде пашет все правда я не уверен что все верно написано, прошу проверить и подсказать как лучше и верней будет

  begin
    Thread.Enter;
    Thread.Execute;
    Thread.Leave;
  end;

Это Вы зря сделали. Критические секции ставятся на участки кода, которые могут из разных потоков конкурентно обращаться к одним и тем же объектам, данным, грубо говоря, а Вы весь поток в в них затолкали. Это ничего не дает: у каждого экземпляра класса своя критическая секция, про которую другие экземпляры не знают, соответственно толку от нее - 0.

[BOBAH13]

Убрал... все вроде работает и так тогда не понятно... зачем синхронизации VCL... что от нее, если я так же все вызываю, правда одна небольшая ошибка есть
Мдя... все-таки синхронизация нужна... как ее реализовать на api пока не понял... буду идти по коду TThread дальше посмотрим что выйдет

[B_N]

Сообщение от BOBAH13

....тогда не понятно... зачем синхронизации VCL...
.......
.......как ее реализовать на api пока не понял...

Данные в VCL, насколько я помню, оформлены очень своеобразно и критическими секциями / семафорами / мутантами никак не перекрыты - разные потоки могут обращаться к свойствам той же формы, скажем к ее размерам, и читать / писать их по своему усмотрению. И хотя фунции GetWindowRect или SetWindowPos выполняются атомарно, за время подготовки этих данных внутри VCL возможна путаница. Классическое объяснение синхронизации выглядит примерно так:
Допустим, что у нас есть некая переменная Х и два потока А и Б.
Поток А выполняет следующее действие над Х:

if X < 100 then inc(X) else X := 0;

Поток Б делает следующее:

if X <> 0 then result := arg / X;

Таким образом, если Х не перекрыта критической секцией (для простых "целых" объектов и простых действий над ними есть еще целая куча Interlocked****** - функций) может случиться так, что поток А присвоит Х значение 0 уже после того, как Б сравнил Х с нулём, но еще до того, как последний приступил к делению. Со всеми вытекающими. Поэтому инициализируется критическая секция (Которую видят оба потока!) и код выглядит примерно так:
Поток А:

...............................
EnterCriticalSection(@CritSection);
if X < 100 then inc(X) else X := 0;
LeaveCriticalSection(@CritSection);
...............................

Поток Б:

...............................
EnterCriticalSection(@CritSection);
if X <> 0 then result := arg / X;
LeaveCriticalSection(@CritSection);
...............................

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

[BOBAH13]

Дело в том... что в потоке грузиться xml файл потом он парситься и динамически сформированная html записуется в документ броузера... если выполнять синхронизацию процедур обработки в TThread все работает прекрасно, как и говорил на счет ехе, в длл лажа... щас пробую вроде выполняется... но броузера видать не устраивает т.к. он мне отображает черт знает что и какой выход... я пока незнаю

[B_N]

Сообщение от BOBAH13

Дело в том... что в потоке грузиться xml файл потом он парситься и динамически сформированная html записуется в документ броузера... если выполнять синхронизацию процедур обработки в TThread все работает прекрасно, как и говорил на счет ехе, в длл лажа... щас пробую вроде выполняется... но броузера видать не устраивает т.к. он мне отображает черт знает что и какой выход... я пока незнаю

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

[BOBAH13]

нет вы не поняли... есть класс поток мой и TThread от них унаследованы два класса типа загрузчика файлов с инета в TStream и парсер xml ...у которого парметры создания указывают на броузер и на текст загруженный (xml), тобиш когда он начнет парсить xml и готовый html после парсинга пихать в броузер то потока который грузил текст уже не будет так что то куда он пихает или что он вообще делает не имеет значение... просто обойтись крит. секциями не получилось

[B_N]

Ааа... Ну тогда просто надо первый поток после окончания парсинга петлить на WaitForSingleObject, к примеру, а во втором, когда он закончит, выставлять какой-нибудь евент, которого ждёт первый, через SetEvent, пока я так понял ситуацию...

[mihali4]

То BOBAH13
Мне кажется, идея с самого начала несколько неправильная - форму "запихивать" в DLL...
Они, в принципе, не для этого предназначались.
Ну, "запихните" туда функции... Из тех, что часто использовать будете...
Я как-то делал такую "байду" (заказали именно так, "понимаш") - в принципе, вся прога получилась в DLL, оставил последователям исходники - до сих пор звонят - спрашивают (а уж 6 лет прошло)... Нетолковое это дело...

[B_N]

Сообщение от mihali4

Мне кажется, идея с самого начала несколько неправильная - форму "запихивать" в DLL...

Вот об этом и речь. Причем если обычные окна на чистом winapi "закручиваются" в dll элементарно, то что там будет VCL вытворять - без отладчика не разберёшься.

[BOBAH13]

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