ReadFileEx - место "повторного вызова".

← →
Riply © (2007-04-25 12:01) [0]

Здравствуйте !
Допустим, у нас есть нить - читатель. Висит и ждет, когда кто-нибудь что-нибудь напишет.
Получив послание, читает его и начинает ждать следующее (вызывает ReadFileEx).
Вызывать ReadFileEx можно в нашей нити (по событию WAIT_IO_COMPLETION):
procedure Overlap_CallBack(cbError: DWord; BytesTransf: DWord; pOverLap: POVERLAPPED); stdcall; begin // Читаем, что-то делаем end; // В нити-читателе case MsgWaitForMultipleObjectsEx(1, hStopEvent, TimeOut, QS_POSTMESSAGE, MWMO_ALERTABLE) of WAIT_IO_COMPLETION: ReadFileEx(hPipe, pData, cbData, @OverLapRead, @Overlapped_CallBack); else //..... end;
А можно вызывать ReadFileEx и в CallBack процедуре (получится что-то типа рекурсии):
procedure Overlap_CallBack(cbError: DWord; BytesTransf: DWord; pOverLap: POVERLAPPED); stdcall; begin // Читаем, что-то делаем if cbError = ERROR_SUCCESS then with PMyOverlap(pOverLap.hEvent) do ReadFileEx(hPipe, pData, cbData, pOverLap, @Overlapped_CallBack); // Если что-то не так, то посылаем сообщение в нить - читатель end; // А в нити-читателе один раз вызвали ReadFileEx и забыли про него (пока он не сообщит об ошибке). Своими делами занимаемся :) case MsgWaitForMultipleObjectsEx(1, hStopEvent, TimeOut, QS_POSTMESSAGE, MWMO_ALERTABLE) of WAIT_OBJECT_0: ..... WAIT_OBJECT_0 + 1: ... else //..... end;
Какой из этих вариантов лучше использовать (конечно, если второй, вообще, имеет право на существование)
и в чем их отличие (кроме, по кол-ва событий WAIT_IO_COMPLETION) ?

← →
Сергей М. © (2007-04-25 12:10) [1]

И тот и другой вариант корректен и имеет право на жизнь.
Но при прочих равных условиях я предпочел бы 2-й.

← →
Riply © (2007-04-25 12:35) [2]

>[1] Сергей М. © (25.04.07 12:10)
>И тот и другой вариант корректен и имеет право на жизнь.
>Но при прочих равных условиях я предпочел бы 2-й.
Спасибо. Тогда продвинемся чуть дальше:
Можно ли твой ответ распространить и на создани нитей-читателей при помощи BindIoCompletionCallback ?
(со своим сообщение вместо WAIT_IO_COMPLETION) ?

← →
Сергей М. © (2007-04-25 13:14) [3]

> Riply © (25.04.07 12:35) [2]

Не знаю, врать не буду.

А зачем тебе BindIoCompletionCallback ? Ты все еще ту прежнюю идею мусолишь ?)

← →
Riply © (2007-04-25 13:24) [4]

> [3] Сергей М. © (25.04.07 13:14)
>А зачем тебе BindIoCompletionCallback ? Ты все еще ту прежнюю идею мусолишь ?)
Сравниваю то и то. У каждого способа есть свои достоинства и свои недостатки.
Так что еще чуть-чуть "помусолю", с твоего разрешения :)
P.S. А за что ты так невзлюбил пулы ? :)

← →
Сергей М. © (2007-04-25 13:35) [5]

> еще чуть-чуть "помусолю", с твоего разрешения

Ладно уж, так уж и быть - мусоль себе на здоровье)... Мне ж не жалко)

> за что ты так невзлюбил пулы ?

В смысле, thread pools ? А причем здесь они ?

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

?

← →
Riply © (2007-04-25 14:11) [6]

> [5] Сергей М. © (25.04.07 13:35)
Значит я еще не научилась ясно излагать свои мысли.
В будущем, когда мой пайповый сервер подрастет и перестанет совершать ошибки :),
я планирую сделать его сервисом. И, соответственно, вижу его таким:
Есть главная нить (с маленьким "временем отклика").
Она отвечает только за обработку команд и запросов
от сервис-менеджера и "глобально" управляет пайповым сервером(пайповыми нитями),
который(которые), в свою очередь занимаются только обслуживанием клиентов.
Ну и, конечно, не хочется заставлять многоуважаемых клиентов простаивать в очереди :)

← →
Сергей М. © (2007-04-25 14:43) [7]

> Riply © (25.04.07 14:11) [6]

> планирую сделать его сервисом

С т.з. концепции и логики организации сервера (пайп или не пайп - не суть как важно) совершенно безразлично, где он будет "жить" - то ли в сервисе, то ли в GUI, то ли в консоли. Так что для полной ясности этот момент можно и вовсе не упоминать. Никогда не поздно перенести свою готовую "отточенную" логику из GUI (или консоли) в сервис или наоборот.

> главная нить отвечает только за обработку команд и запросов
> от сервис-менеджера и "глобально" управляет пайповым сервером(пайповыми нитями),
> который(которые), в свою очередь занимаются только обслуживанием клиентов.

Тогда есть полное основание назвать эту нить транспорно-диспетчерской.

За малое время отклика можно не волноваться, если траспортные ф-ции, исполняемые этой нитью, реализованы с использованием overlapped-операций ввода/вывода или механизма колбэков, т.е. в твоем случае те самые Read/WriteEx-вызовы.

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

← →
Riply © (2007-04-25 15:39) [8]

> [7] Сергей М. © (25.04.07 14:43)
Спасибо.
С самым главным - общей структурой и терминологией, разобрались.
Осталось дело за малым - реализацией :)

> Riply © (25.04.07 15:39) [8]

Дерзай !

Барышня ты, как минимум, "при голове")..
Сие признаю и сие весьма приятно, тэкскэть, "на фоне")

> Ой не загордись только !)

Интересно какой тогда ник будет :)

ReadFileEx - место "повторного вызова". Найти похожие ветки