Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Diablo © (2003-12-09 23:16:00)

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

Создаю поток 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? Подскажите логику!

Digitman (2003-12-27 14:00:00) [1]

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

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

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

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

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

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

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

Diablo (2003-12-27 13:17:00) [2]

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

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

Digitman (2003-12-18 08:33:00) [3]

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

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

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

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

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

Diablo (2003-12-17 17:42:00) [4]

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

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

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

Digitman (2003-12-17 08:16:00) [5]

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

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

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

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

Digitman (2003-12-13 14:52:00) [7]

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

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

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

Diablo (2003-12-13 14:31:00) [8]

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-10 18:55:00) [9]

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

Sandman25 (2003-12-10 18:51:00) [10]

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

Diablo (2003-12-10 18:50:00) [11]

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »