Форум: "Сети";
Текущий архив: 2004.03.03;
Скачать: [xml.tar.bz2];
ВнизСоздание компонент в потоках Найти похожие ветки
← →
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.
У меня остался только один вопрос - а как определять, что соединение разорвано удаленной стороной?
← →
Digitman (2003-12-18 08:33) [9]
> И получится почти тоже самое, что и с ctBlocking
это почему же ? blocking-режим - синхронный, non-blocking же - асинхронный ... разница-то весьма ощутимая с т.з. построения транспортного алгоритма ! ... и неважно, в каком код.потоке все это дело будет происходить!
> как определять, что соединение разорвано удаленной стороной
в случае неблок.режима корректный разрыв соединения по инициативе партнера будет отражен фактом возбуждения события OnDisconnect()
в случае блок.режима попытка выполнения любого метода приема/передачи при уже несуществующем соединении вызовет программное исключение, которое и можно считать фактом разрыва соединения
← →
Diablo (2003-12-27 13:17) [10]в доп.код.потоке нужно организовать цикл ожидания/выборки/диспетчеризации оконных сообщений, по аналогии с тем, который автоматически запускается в осн.код.потоке при вызове Application.Run
стоп. А каких оконных сообщений? Окно-то одно - окно программы. А потока два.
← →
Digitman (2003-12-27 14:00) [11]
> А каких оконных сообщений?
тех самых, что посылает гнездо при возникновении асинхронных трансп.событий
не знаю как в TTCPClient, но в TClientSocket, если он инициализируется как ctNonBlocking, создается спец.невидимое окно и в дальнейшем (в ходе работы TClientSocket) инф-ция обо всех происходящих трансп.событиях передается в виде специальных оконных сообщений этому окну... оконная ф-ция этого окна анализирует принятые сообщения и в зависимости от каждого конкретного воздуждает соответствующие события уже самого компонента TClientSocket (OnConnect(), OnDisconnect(), OnRead(), OnWrite(), OnError())
> Окно-то одно - окно программы. А потока два
каждый из кодовых потоков, существующих в контексте процесса, если он создает одно окно (или более), обязан организовать собственный цикл ожидания/выборки/диспетчеризации сообщений, посылаемых кем бы то ни было этому окну
основное окно приложения создается в осн.код.потоке, а цикл создается и запускается автоматически в методе Application.Run
но ! доп.код.поток, создавший и инициализировавший TClientSocket, создал тем самым и как минимум еще одно (свое) окно (это делается неявно, в ходе внутренней активизации трансп.ф-ций компонента), а, значит, он - доп.код.поток - и становится ответственным за организацию цикла ! За него это никто и ничто не сделает
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2004.03.03;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.006 c