I'm using pipes and I got a kind of deadlock on WriteFile/ReadFile. Here is my code :
hProbePipeRet = CreateNamedPipe(
"\\\\.\\pipe\\probePipeRet", // pipe name
PIPE_ACCESS_DUPLEX, // read/write access
PIPE_TYPE_MESSAGE | // message type pipe
PIPE_READMODE_MESSAGE | // message-read mode
PIPE_WAIT, // blocking mode
PIPE_UNLIMITED_INSTANCES, // max. instances
BUFSIZE, // output buffer size
BUFSIZE, // input buffer size
5, // client time-out
NULL); // default security attribute
First I create my pipe, then I use it like this in anot开发者_运维问答her application:
WriteFile(
hProbePipeRet, // handle to pipe
msg.c_str(), // buffer to write from
msg.size(), // number of bytes to write
&dwBytesWritten, // number of bytes written
NULL); // not overlapped I/O
And I receive it back with :
fSuccess = ReadFile(
myInst->hProbePipeRet, // handle to pipe
buf, // buffer to receive data
BUFSIZE, // size of buffer
&dwBytesRead, // number of bytes read
NULL); // not overlapped I/O
This is very basic and I have two more pipes that do EXACLY the same thing, the only difference is that they are in a different thread, but I need this one only for basic transactions of message.
On the first try, the informations on the pipes are read successfully, but on the second try, if I don't send at least BUFSIZE of data, both WriteFile and ReadFile will block. As I said, I have two more pipes that do the same thing, with the same functions and I don't need to send BUFSIZE of data to have a successful communication.
EDIT : Additionnal infos
The execution goes as follow : A message is sent to the server by pipe1, the message is received then it returns data with hProbePipeRet in my problematic code. The data is read by the client, printed to the screen.
Another message is dispatched using pipe1, received and the result goes again in hProbePipeRet, the client is waiting for at least BUFSIZE of information and I don't know what the server is doing but it's blocked at WriteFile.
This scenario is the same as my others pipes but I don't put hProbePipeRet in a seperate thread to read from it. I'm doing this because I need an answer right after I dispatched the message.
Perhaps you have the problem that you use blocking IO. The call to ReadFile blocks until there is something to read. If you have a loop that calls write and then read it may block in the second call. Perhaps you should consider using async io. You call the readFile with a event. The event gets set when there is something to read. So there is no need to create multiple threads.
use PIPE_TYPE_BYTE
and PIPE_READMODE_BYTE
instead of the MESSAGE counter parts. Also the server must not perform any blocking read operations before any client has connected.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx
Edit: For the 'must not perform any blocking read operations': This can, according the the documentation lead to a race condition which actually might be your case, however it is hard to tell without seeing more of your code.
精彩评论