C++ GetQueuedCompletionStatus过早退出（或者我认为是这样）

让我先概述一下。我通过三个端口接收数据。我有一个套接字、一个完成端口和一个工作线程。我调用WSARecv，工作线程进程调用GetQueuedCompletionStatus，后跟我的解析例程ReadMsgs。有时，在调用ReadMsgs时，缓冲区会保持不变，而在ReadMsgs处理缓冲区时，缓冲区会更新。GetQueuedCompletionStatus返回的已处理字节数在更新发生时是正确的

有人知道为什么会发生这种情况，我做错了什么吗。让我向您展示最相关的代码。如果您需要查看更多代码，请具体说明。我的基本socket类如下所示（我省略了我认为不相关的细节。我还省略了所有错误检查。）

每个端口都有自己的派生套接字类，通过端口号和虚拟ProcessMsg函数（在解析每条消息时由ReadMsgs调用）进行区分。这里有一个这样的类：

class Socket_Admin : public Socket_Base
{
public:
static const int bufcap = 1024;
Socket_Admin::Socket_Admin() : Socket_Base()
{
    // Buffer
    readBuf = new char[ bufcap];

    // The socket
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = inet_addr("127.0.0.1");
    addr.sin_port = htons(9300);
    wsaBuf.buf = readBuf;
    wsaBuf.len = bufcap;
}
~Socket_Admin();
void ProcessMsg();
};

工作线程进程是

unsigned int Callback_Socket( void *lpParameter)
{
    HANDLE hCP = (HANDLE)lpParameter;
    DWORD NumBytes = 0;
    ULONGLONG CompletionKey;
    WSAOVERLAPPED *pOverlapped;
    while (GetQueuedCompletionStatus( hCP, &NumBytes, &CompletionKey, &pOverlapped, INFINITE) && CompletionKey == 0)
    {
        Socket_Base *pTCP = (Socket_Base*)pOverlapped;
        if (NumBytes > 0) pTCP->ReadMsgs( NumBytes);
        NumBytes = 0;
    }
    return 0;
}

还有一件事我要解释。ReadMsgs在适当的位置进行解析。服务器用最后一个换行符分隔消息，并用逗号分隔消息中的字段。ReadMsgs在查找逗号和换行符时使用空字符替换逗号和换行符，并在指向缓冲区中位置的单独指针数组中记录每个字段的起始位置。现在，当ReadMsgs到达上次填充的缓冲区区域的末尾时，它有时会发现一条不完整的消息。这将复制到缓冲区的开头，期望下一次读取完成消息，并相应地修改wsaBuf。因此，ReadMsgs的结尾如下所示：

wsaBuf.buf = pchar;
wsaBuf.len = remsize;
StartRecv();

其中，pchar指向部分消息后面的字符，remsize是剩余缓冲区的大小

我知道从详细的服务器日志中向我的应用程序发送了哪些消息。用空字符替换分隔符还可以很容易地看到缓冲区的哪一部分已被处理。通过将缓冲区保存到文件并检查它，我可以看出它是在调用ReadMsgs后更新的。另外，通过上面代码中未显示的日志消息，我知道在这些情况下，工作线程调用了ReadMsgs。它不是每次都发生，但确实发生了

---

如果有人能告诉我我的错误是什么，我将不胜感激。

我可能有答案。我在StartRecv和Callback\u套接字中都调用了ReadMsgs。在StartRecv中，当WSARecv返回0时，我调用ReadMsgs，表示传输由WSARecv完成。我在想，如果传输在WSARecv中完成，那么GetQueuedCompletion状态将不会涉及。但是，如果GetQueuedCompletionStatus确实返回对已完成读取的响应，那么我将重复调用ReadMsgs，这将解释我收集的日志数据，就像我以前的假设一样

我已经删除了对StartRecv中ReadMsgs的调用。代码现在运行正常

---

多亏了投我反对票的那位先生。这向我表明，我所描述的行为以前从未被观察到，因此极不可能。这让我想到了一个新的方向。有时只是一些更有经验的人发出的咕哝声。

我可能有答案。我在StartRecv和Callback\u套接字中都调用了ReadMsgs。在StartRecv中，当WSARecv返回0时，我调用ReadMsgs，表示传输由WSARecv完成。我在想，如果传输在WSARecv中完成，那么GetQueuedCompletion状态将不会涉及。但是，如果GetQueuedCompletionStatus确实返回对已完成读取的响应，那么我将重复调用ReadMsgs，这将解释我收集的日志数据，就像我以前的假设一样

我已经删除了对StartRecv中ReadMsgs的调用。代码现在运行正常

多亏了投我反对票的那位先生。这向我表明，我所描述的行为以前从未被观察到，因此极不可能。这让我想到了一个新的方向。有时只是一些更有经验的人发出的咕哝声

wsaBuf.buf = pchar;
wsaBuf.len = remsize;
StartRecv();