Всем, Добрый вечер!
У меня имеется следующий острый вопрос. При передачи данных посредством именованных каналов в асинхронном режиме возможно ли организовать событийную реакцию на обработку состояний канала?
Есть ли механизм отслеживания готовности данных в канале для считывания, подобный функции
WSAAsyncSelect в реализации сокетов. ???
Заранее благодарен.

Здравствуйте, AviSergey, Вы писали:

AS>Всем, Добрый вечер!
AS>У меня имеется следующий острый вопрос. При передачи данных посредством именованных каналов в асинхронном режиме возможно ли организовать событийную реакцию на обработку состояний канала?
AS>Есть ли механизм отслеживания готовности данных в канале для считывания, подобный функции
AS>WSAAsyncSelect в реализации сокетов. ???
AS>Заранее благодарен.

Вы имеете в виду, извещать Ваш код автоматической посылкой оконных сообщений? Нет, но при желании это можно эмулировать. Я так понимаю, речь идёт о реализации клиентского конца? Потому как в использовании той-же WSAAsyncSelect на сервере смысла нет, из-за "тяжеловесности" этого механизма.

Пайпы в этом плане ничем не отличаются от любого другого файлового устройства. Для клиента можно воспользоваться MsgWaitForMultipleObjects с "локальной" петлёй сообщений. Либо отдельным потоком, из которого посылать сообщения UI-потоку. Или даже пулом, своим или системным, или Completion port, хотя на клиенте в этом очень редко есть смысл. Однако не стоит слишком жёстко связывать транспортный уровень с остальными.

Здравствуйте, Мизантроп, Вы писали:

М>Здравствуйте, AviSergey, Вы писали:

М>Вы имеете в виду, извещать Ваш код автоматической посылкой оконных сообщений? Нет, но при желании это можно эмулировать. Я так понимаю, речь идёт о реализации клиентского конца? Потому как в использовании той-же WSAAsyncSelect на сервере смысла нет, из-за "тяжеловесности" этого механизма.

М>Пайпы в этом плане ничем не отличаются от любого другого файлового устройства. Для клиента можно воспользоваться MsgWaitForMultipleObjects с "локальной" петлёй сообщений. Либо отдельным потоком, из которого посылать сообщения UI-потоку. Или даже пулом, своим или системным, или Completion port, хотя на клиенте в этом очень редко есть смысл. Однако не стоит слишком жёстко связывать транспортный уровень с остальными.

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