Ломать ReadFile() блокирование - именованный канал (Windows API)

Question

Для упрощения, это ситуация, когда именованный канал SERVER ждет для именованного канала КЛИЕНТА писать к трубе (с помощью WriteFile())

В Windows API что блокирование является ReadFile()

сервер создает синхронное трубу (не внахлест I/O) с блокировкой позволило

клиент подключен, и теперь сервер ждет некоторых данных.

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

Между тем происходит событие (например, пользовательский ввод), а сервер NamedPipe SERVER должен выполнить другой код, который он не может выполнять, пока блокирует ReadFile().

На этом этапе я должен упомянуть, что клиент NamedPipe не является моим приложением, поэтому я не могу контролировать его. Я не могу заставить его отправить несколько байтов, чтобы разблокировать сервер. Он просто сидит и не посылает никаких данных. Поскольку я не контролирую реализацию Клиента, я ничего не могу изменить с этой целью.

Одним из решений было бы создать отдельный поток, в котором выполняются все операции ReadFile(). Таким образом, когда событие происходит, я могу просто обработать код. Проблема в том, что для события также требуется отдельный поток, поэтому теперь у меня есть два дополнительных потока для каждого экземпляра этого сервера. Поскольку это должно быть масштабируемым, это нежелательно.

С другой нити я попытался назвать

DisconnectNamedPipe() 

и

CloseHandle() 

оба они не будут возвращаться (до тех пор, пока клиент не пишет в трубу.)

Я не могу подключиться к тот же трубопровод и написать несколько байтов, потому что:

«Все экземпляры имени pipe имеет одно и то же имя канала, но каждый экземпляр имеет свои собственные буферы и дескрипторы и предоставляет отдельный канал для связи клиент/сервер ».

http://msdn.microsoft.com/en-us/library/aa365590.aspx

Мне нужен способ фальсифицировать это, так что доллар вопрос, $ 64k является:

Как я могу сломать блокировку ReadFile()?

Answer 1

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

Никогда в моей карьере я не обнаружил, что «больше потоков» == «менее масштабируемо». Сколько из этих «серверных» экземпляров у вас есть?

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

Answer 2

Mike,

Вы не можете отменить синхронный ReadFile. Но вы можете переключиться на асинхронные (перекрывающиеся) операции. Делая это, вы можете реализовать довольно масштабируемую архитектуру.

Возможный алгоритм (только идея):

• Для каждого нового клиента вызова ReadFile
• WaitForMultipleObjects где ручки overlapped.hEvent + ваши пользовательские события
• перебрать сигнальное события и расписание их для выполнения потоками из пула потоков.

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

Answer 3

Посмотрите на CancelSynchronousIo

Marks в ожидании синхронного ввода/вывода операции, выпущенные указанного потока расторгнутым.

И CancelIo/CancelIoEx:

Чтобы отменить все ожидающие асинхронный ввод/вывод операции можно использовать:

CancelIo - эта функция отменяет только операций, выданную вызывающей резьбой для указанный дескриптор файла.

CancelIoEx - эта функция отменяет все операции , выданные потоками для указанного дескриптора файла.

• http://msdn.microsoft.com/en-us/library/aa363794(VS.85).aspx
• http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx

Answer 4

асинхронные операции ввода/вывода не должны блокировать любые темы, если они используют порты ввода/вывода завершения. См: http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx

Answer 5

Попробуйте это перед ReadFile:

BOOL WINAPI PeekNamedPipe(
    __in  HANDLE hNamedPipe, 
    __out_opt LPVOID lpBuffer, 
    __in  DWORD nBufferSize, 
    __out_opt LPDWORD lpBytesRead, 
    __out_opt LPDWORD lpTotalBytesAvail, 
    __out_opt LPDWORD lpBytesLeftThisMessage 
); 

if(TotalBytesAvail > 0) 
    ReadFile(....); 

-AV-

Answer 6

Что происходит, сервер исходящей трубы остается открытым, ожидая связи в то время как клиент пытается подключиться к серверу Входящее (который больше не существует). Что вам нужно сделать, это вымыть ваш исходящий канал, чтобы вернуться к вашему входящему потоку.Вы можете выполнить очистку на стороне клиента, прочитав файл (не забудьте установить соединение, потому что там есть «рукопожатие», и он никогда не будет работать в первый раз)