ProcessMessages

← →
Tommy (2003-10-01 13:30) [0]

Доброго времени дня всем !!!
Вот такая проблемма представилась...
Имеется прога которая делает кучу всяких расчетов в циклах... и одновременно получает данные по socketu ...
Пока не добавила кругом в эти циклы "ProcessMessages" сокет не срабатывал... то есть событие SocketRead не работало... терялись данные... теперь положение вроде исправленно... но решение мне кажется ненадежным..... какой другой выход существует из этого положениа???

← →
Digitman (2003-10-01 13:33) [1]

> решение мне кажется ненадежным

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

← →
Digitman (2003-10-01 13:40) [2]

> то есть событие SocketRead не работало... терялись данные

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

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

← →
clickmaker (2003-10-01 13:47) [3]

> Tommy

А почему бы не читать из сокета в отдельном потоке ?

← →
Tommy (2003-10-01 18:07) [4]

>>Digitman

дело в том Что я Читаю только в событие OnRead спомощью
ReadText...похоже придется Читать и вне него :)

>>clickmaker
а вот про это я уже две недели спрашиваю
и никто примера не дает :(
никогда мне не приходилось Читать из сокета в другом потоке :(
если можете то пожалуйста пришлите пример как это сделать...
только имеется ввиду неблокируещее соединие

← →
Digitman (2003-10-01 18:15) [5]

> Tommy

читать-то можно где угодно, в любом месте кода

но событие OnRead возбуждается именно когда буфер приема гнезда заведомо не пуст

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

← →
Tommy (2003-10-01 18:19) [6]

а почему же тогда когда буфер не пуст OnRead не может прервать мой While или For???
извините за такие "странные" вопросы:)

← →
clickmaker (2003-10-01 18:36) [7]

> Tommy (01.10.03 18:07) [4]

Ну так примерно. Только сокет д.б. блокирующим

procedure TSocketThread.Execute; var Stream: TWinSocketStream; begin Stream := TWinSocketStream.Create(Socket,60000); try while not Terminated do begin Stream.WaitForData(100); Stream.Read(Buffer, BuffSize); end; finally Stream.Free; end; end; procedure ClientSocket1Connect(Sender: TObject; Socket: TCustomWinSocket); begin Thread := TSocketThread.Create(true); Thread.Socket := Socket; Thread.Resume; end; procedure ClientSocket1Disconnect(Sender: TObject; Socket: TCustomWinSocket); begin Thread.Terminate; end;

← →
Anatoly Podgoretsky (2003-10-01 19:32) [8]

Tommy (01.10.03 18:19) [6]
А вот для жтого и нужен ProcessMessages

← →
Tommy (2003-10-02 16:07) [9]

>>clickmaker

насколько я поняла... когда клиент открывает поток для общения с сервером тогда на сервере срабативает OnGetThread...
Значит каждого клиента будет обрабативать отдельный поток, так?
А до скольки клиентов я могу запустить?
А не для блокирущих сокетов OnGetThread не работает?

← →
Digitman (2003-10-02 16:35) [10]

> Tommy (01.10.03 18:19) [6]
> а почему же тогда когда буфер не пуст OnRead не может прервать
> мой While или For???
> извините за такие "странные" вопросы:)

а с какого перепугу кто-то кого-то должен "прерывать" ?
в конкретном код.потоке вызвана и выполняется некая процедура, и до тех пока она не не завершится, другая процедура сама по себе не будет вызвана на выполнение ! Если только выполняющаяся процедура ее сама не вызовет тем или иным образом ... собссно, это и происходит в недрах "загадочного" метода ProcessMessages)

ради эксперимента забрось все свои "сокеты" на время, брось на форму таймер, задай ему период секунду, в его обработчике напиши что-то типа ShowMessage("Обрабатывается событие таймера"), установи Timer.Enabled := True, запусти все это хозяйство на выполнение

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

← →
Tommy (2003-10-02 17:29) [11]

>>Digitman
ясно как божий день!!! :)
ещё один вопросик по-поводу.... если таимер не отключить входя в него... и если он опять застучит до окончания выполнения своего тела то Что происходит?

← →
ЮЮ (2003-10-03 04:52) [12]

А говоришь, что ясно :-)
Если внутри обработчика таймера нет ProcessMessages, то как бы он не стучал, будет выполняться код обработчика, т.е. стука ты не услышишь

← →
ЮЮ (2003-10-03 04:56) [13]

А вот если внутри обработчика поставить ProcessMessages, то стук будет услышан и будет вызван новый обработчик таймера, а продолжение первого будет продолжено уже после и т.д.

← →
Digitman (2003-10-03 08:06) [14]

> Tommy (02.10.03 17:29) [11]

<ЮЮ> уже ответил тебе)

← →
Anatoly Podgoretsky (2003-10-03 08:45) [15]

Tommy (02.10.03 17:29) [11]
Ничего не происходит, пока не будут обработаны сообщения (ProcessMessages), а что нехорошого может произойти, написал ЮЮ © (03.10.03 04:52) [12], может произойти зацикливание, только ты добавь к ответу следующее, ProcessMessages может быть вызван не только из обработчика, но и из любого места.
Задача состоит в том, чтобы подобного не допускать, обработчик должен быть выполнен, с большим запасом до возникновения нового события, иначе система будет нестабильная или не предсказуемая.

← →
Tommy (2003-10-03 13:02) [16]

спасибо всем!!!

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