Потоки

← →
Dj Karies (2002-09-04 10:51) [0]

Как заставить Delphi работать с потоками в Dll?
В exe-файле потоки без проблем работают, в dll - нет, приложение валится и иногда валит систему.
Поток, созданный на ActivX-форме вешает Windows.
Ложишь анимированный TGifImage на ActiveX-форму и жми Reset.

← →
Слесарь Матерящийся (2002-09-04 11:04) [1]

>Как заставить Delphi работать с потоками в Dll?

Не использовать TThread, работать через WinAPI.
CreateThread()........ и т.д.

← →
NailS (2002-09-04 11:22) [2]

Странно, с потоками в dll никогда проблем не было ;)

В чем конкретно проблема?

> Не использовать TThread, работать через WinAPI.
> CreateThread()........ и т.д.

А что, теперь TThread не через CreateThread() создается? ;)

← →
Digitman (2002-09-04 11:33) [3]

>Dj Karies

Самый первый экз-р класса TThread должен создаваться в осн.код.потоке хост-процесса, загрузившего DLL. По кр.мере - в Д5.
Если это условие не соблюдено, как раз и получишь све те "прелести жизни" , о которых ты здесь поведал)

← →
Digitman (2002-09-04 11:42) [4]

>NailS

> теперь TThread не через CreateThread() создается?

А как это вообще себе представляешь - создать VCL-объект "через" WinAPI-ф-цию ?

> с потоками в dll никогда проблем не было

Были. И есть. По кр.мере - вплоть ло Д5. И, скорее всего, рекомендация коллеги <Слесарь> правильна.

← →
NailS (2002-09-04 11:52) [5]

> Digitman © (04.09.02 11:42)
> >NailS
> > теперь TThread не через CreateThread() создается?
> А как это вообще себе представляешь - создать VCL-объект
> "через" WinAPI-ф-цию ?

Не точно выразился, не "через", а "используя(вызывая)CreateThread()".

← →
Digitman (2002-09-04 12:06) [6]

>NailS

Да дело даже не в этом. Кроме инкапсуляции API-ф-ций менеджера потоков, класс TThread много еще чего делает. Вот в этом-то "много чего еще" и вся загвоздка.

← →
Digitman (2002-09-04 12:10) [7]

>NailS

Да дело даже не в этом. Кроме инкапсуляции API-ф-ций менеджера потоков, класс TThread много еще чего делает. Вот в этом-то "много чего еще" и вся загвоздка. Проблема - в особенностях реализации всего того, что кроется под методом Synchronize()

← →
NailS (2002-09-04 12:46) [8]

> Digitman ©

При создании TThread только добавляет себя в глобальный список потоков, и создает нить, вызывая CreateThread().
Принципиальных отличий при использовании просто CreateThread() ИМХО нет.

> Проблема - в особенностях реализации всего того, что кроется
> под методом Synchronize()

А я и не заметил, что Synchronize() в шестерке переписали, раньше создавалась глобальное окно, в которое сендилось сообщение, а в шестерке этот метод постит сообщение используя WakeMainThread в главное окно и ждет события, которое выставляется в сигнальное состояние после выполнения метода.

И, пожалуй, совет Слесаря, можно упростить до рекомендации не использовать Synchronize() для синхронизации потоков в dll.

← →
Слесарь Матерящийся (2002-09-04 12:57) [9]

Win API. Куда уж проще?!
:o)

← →
Digitman (2002-09-04 13:11) [10]

Очередь сообщений окну по-умолчанию доступны лишь тому код.потоку, который его (окно) создал. И обработка этих сообщений, соответственно, будет выполняться в этом же код.потоке.
Так вот в этом-то и проблема, что в Д5 окно создается при первом вызове конструктора TThread, и если конструктор был вызван не в осн.код.потоке, то и созданное окно будет принадлежать тому же потоку. Соответственно, и сообщение CM_EXECPROC будет обрабатываться не в осн.потоке. Как результат, метод, указанный в Synchronize(), будет выполнен не в осн.потоке (как ожидалось), а в дополнительном.

Возражу - нельзя так упрощать совет <Слесаря> : он годен лишь для описанной мной ситуации. Именно эту ситуацию я и предполагаю, поскольку ActiveX-объект вполне может создаваться в доп.потоке (например, при обращении к фабрике класса из скрипта, исполняемого IE). При конструировании экземпляра вполне может создаваться тот самый TThread, что и вызывает последующую проблему с "подвисаниями", когда в какой-то момент в его методе Execute() будет вызван Synchronize(), например, для обновления содержимого окна в составе TGifImage

← →
Digitman (2002-09-04 13:21) [11]

И еще.

1. Я не знаю, что такое TGifImage - среди стандартных его вроде бы нет. И это наводит на подозрения, что наличие и корректность обработки исключений в TThread.Execute() в его составе оставляет желать лучшего

2. Выяснить предположение проще простого : коль ActiveX-объект собственной "закваски", достаточно в разделе инициализации формы (на которой "лежит" этот самый TGifImage) вставить на время отладки проверку на равенство ID тек.потока ID осн.потока хост-процесса.

← →
NailS (2002-09-04 13:27) [12]

> Слесарь Матерящийся (04.09.02 12:57)
> Win API. Куда уж проще?!

[off]
К сожалению, Win API не всегда просто ;(. Проще использовать надстройки над ним, враперы, правда иногда это может привести к печальным последствиям
[/off]

Потоки Найти похожие ветки