Ответов: 9906
Рейтинг: 351
|
tsdima, посмотрел я немного теорию, и вот что вижу (не смотря на то, что у меня все работает):
собственно, из bError=true еще не следует (чисто логически) что не вычитан весь буфер именно из hPipeOutputRead
как бы не увидел в MSDN проверки закрытия каналов со стороны клиента методом проверки PeekNamedPipe. Там рассказывают про возврат 0-ка через ReadFile
MSDN писал(а): To read from the pipe, use the pipe's read handle in a call to the ReadFile function. The ReadFile call returns when another process has written to the pipe. The ReadFile call can also return if all write handles to the pipe have been closed or if an error occurs before the read operation has been completed.
но для этого, хэндлы каналов со стороны сервера hPipeErrorsRead, hPipeOutputRead, hPipeInputWrite не должны наследоваться дочерним процессом.
Про Read-End цитата выше, а про Write-End вот:
MSDN писал(а): In this case, the parent process must ensure that the child process does not inherit the pipe's write handle. If this is not done, the ReadFile operation performed by the child process cannot return zero because the child process has an open handle to the write end of the pipe
Поскольку мы не должны полагаться на конкретный код клиента, то должны следовать общим правилам, и не передавать в наследование серверные хэндлы каналов hPipeErrorsRead, hPipeOutputRead, hPipeInputWrite
А клиентские хэндлы каналов hPipeErrorsWrite, hPipeOutputWrite, hPipeInputRead должны закрывать сразу же после создания процесса
в принципе, закрытие каналов hPipeErrorsWrite ИЛИ hPipeErrorsWrite - еще не означает закрытия консоли. Это вообще-то - сигнальное состояние для hProcess
вообще-то, при создании процесса, мы лочим не только pi.hProcess, но и pi.hThread
Ему тоже надо бы говорить CloseHandle
|
| карма: 9 |
|  0 |
|
Поиск
Друзья
Администрация