Создание компонент в потоках

← →
Diablo (2003-12-09 23:16) [0]

Вот делаю тут в своем чате поддержку передачи файлов. Как понимаю, лучше всего делать ее через потоки, только не пойму как именно:

Создаю поток Thread1: TSendThread, допустим. Запускаю его. В нем что-то типа:

procedure TSendThread.Execute;
var Sock:TTCPClient;
begin
Sock:=TTCPClient.create(nil);
Sock.port:="...";
Sock.host:="...";
Sock.connect;
end;

Вроде все логично, после Connect мне нужна дождаться события OnConnect и продолжать работу... но ведь поток, видимо, завершится после строчки Sock.Connect и будет уничтожен. Вообще, произойдет потеря ресурсов (Sock).

Ну а как быть, не пойму... и кому вообще назначать обработку события Sock.OnConnect? Подскажите логику!

← →
Diablo (2003-12-10 18:50) [1]

Мастера, вы где?

← →
Sandman25 © (2003-12-10 18:51) [2]

При вызове Socket.Connect произойдет вызов обработчика события OnConnect.

← →
Digitman © (2003-12-10 18:55) [3]

в общем случае можно вполне обойтись и без ожидания/обработки событий. если перед открытием гнезда установить св-во Sock.ClientSocket := ctBlocking

← →
Diablo (2003-12-13 14:31) [4]

Digitman, не понимаю, ну будет так:

procedure TSendThread.Execute;
var Sock:TTCPClient;
begin
Sock:=TTCPClient.create(nil);
Sock.ClientSocket := ctBlocking;
Sock.port:="...";
Sock.host:="...";
Sock.connect;
Sock.SendLn("Hi");
end;

А толку? Ведь мне нужно дождаться ответа, в зависимости от него посылать что-то еще! Но ведь после процедуры Sock.SendLn("Hi"); поток завершится! Как же быть, что делать - я этого не пойму.

Кому назначать обработку события Sock.OnConnect и других?

← →
Digitman © (2003-12-13 14:52) [5]

> Ведь мне нужно дождаться ответа

ну у жди на здоровье ! кто ж мешает ?

Sock.SendLn("Hi"); //поздоровались
Answer := Sock.ReadLn(...); // ждем ответного приветствия

← →
Diablo (2003-12-16 18:54) [6]

Digitman
ок, все понял. А как с потоками организовать, но без ctBlocking?

← →
Digitman © (2003-12-17 08:16) [7]

> А как с потоками организовать, но без ctBlocking?

в доп.код.потоке нужно организовать цикл ожидания/выборки/диспетчеризации оконных сообщений, по аналогии с тем, который автоматически запускается в осн.код.потоке при вызове Application.Run

← →
Diablo (2003-12-17 17:42) [8]

в доп.код.потоке нужно организовать цикл ожидания/выборки/диспетчеризации оконных сообщений

А, ну понятно. И получится почти тоже самое, что и с ctBlocking.

У меня остался только один вопрос - а как определять, что соединение разорвано удаленной стороной?

> И получится почти тоже самое, что и с ctBlocking

это почему же ? blocking-режим - синхронный, non-blocking же - асинхронный ... разница-то весьма ощутимая с т.з. построения транспортного алгоритма ! ... и неважно, в каком код.потоке все это дело будет происходить!

> как определять, что соединение разорвано удаленной стороной

в случае неблок.режима корректный разрыв соединения по инициативе партнера будет отражен фактом возбуждения события OnDisconnect()

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

← →
Diablo (2003-12-27 13:17) [10]

в доп.код.потоке нужно организовать цикл ожидания/выборки/диспетчеризации оконных сообщений, по аналогии с тем, который автоматически запускается в осн.код.потоке при вызове Application.Run

стоп. А каких оконных сообщений? Окно-то одно - окно программы. А потока два.

> А каких оконных сообщений?

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

не знаю как в TTCPClient, но в TClientSocket, если он инициализируется как ctNonBlocking, создается спец.невидимое окно и в дальнейшем (в ходе работы TClientSocket) инф-ция обо всех происходящих трансп.событиях передается в виде специальных оконных сообщений этому окну... оконная ф-ция этого окна анализирует принятые сообщения и в зависимости от каждого конкретного воздуждает соответствующие события уже самого компонента TClientSocket (OnConnect(), OnDisconnect(), OnRead(), OnWrite(), OnError())

> Окно-то одно - окно программы. А потока два

каждый из кодовых потоков, существующих в контексте процесса, если он создает одно окно (или более), обязан организовать собственный цикл ожидания/выборки/диспетчеризации сообщений, посылаемых кем бы то ни было этому окну

основное окно приложения создается в осн.код.потоке, а цикл создается и запускается автоматически в методе Application.Run

но ! доп.код.поток, создавший и инициализировавший TClientSocket, создал тем самым и как минимум еще одно (свое) окно (это делается неявно, в ходе внутренней активизации трансп.ф-ций компонента), а, значит, он - доп.код.поток - и становится ответственным за организацию цикла ! За него это никто и ничто не сделает

Создание компонент в потоках Найти похожие ветки