Question

I have a COM component, implemented in C++ with ATL, that uses overlapped socket I/O. Right after the connection is made to the server, it starts an overlapped read on the socket, with code like this:

// Pass pointer to this instance as hEvent parameter, for use by callback
m_recvOverlapped.hEvent = reinterpret_cast<HANDLE>(this);

int rc = ::WSARecv(m_s, &wsabuf, 1, &m_recvNumberOfBytes, &m_recvFlags, &m_recvOverlapped, RecvCallback);
if (rc == SOCKET_ERROR)
{
    // If error is WSA_IO_PENDING, then the I/O is still in progress.  Otherwise, something bad happened.
    int error = ::WSAGetLastError();
    if (error != WSA_IO_PENDING)
    {
        ReceiveError(error);
    }
}

And I have a callback function that looks something like this:

void CALLBACK CMySocket::RecvCallback(DWORD dwError, DWORD cbTransferred, LPWSAOVERLAPPED lpOverlapped, DWORD dwFlags)
{
CMySocket* socket = reinterpret_cast<CMySocket*>(lpOverlapped->hEvent);
ATLASSERT(socket != 0);
if (!socket)
    return;

socket->ReceiveCompleted(dwError, cbTransferred, lpOverlapped, dwFlags);
}

This COM component works fine in unit tests, when used in a command-line app, and when used in a .NET GUI app (via COM interop). However, when I use this component in an MFC app, the RecvCallback never gets called when the server sends data to it.

WSARecv() returns SOCKET_ERROR, and WSAGetLastError() returns WSA_IO_PENDING, as expected for asynchronous overlapped reads.

When I use the SysInternals TcpView app to watch what’s happening, it indicates that the client is receiving data. But the callback is never being called.

Sending data to the server through the connected socket works fine.

I am calling CoInitializeEx() and WSAStartup() in my MFC app’s InitInstance() method.

Any ideas?

Answer 1

OK, I found the answer by searching for other Stack Overflow questions regarding WSARecv.

From Len Holgate’s answer to Win32 Overlapped I/O – Completion routines or WaitForMultipleObjects?:

. . . you can pass a completion routine which is called when completion occurs. This is known as ‘alertable I/O’ and requires that the thread that issued the WSARecv() call is in an ‘alertable’ state for the completion routine to be called. Threads can put themselves in an alertable state in several ways (calling SleepEx() or the various EX versions of the Wait functions, etc). . . .

It turns out that if I start a timer in the MFC app that periodically calls SleepEx(0, TRUE), then the receive callback gets called. So the problem is that the main MFC thread that calls my COM object’s method that calls WSARecv() never goes into an alertable state on its own.

So, I’ll probably need to change my COM object’s implementation so that it uses I/O completion ports rather than callbacks, or starts its own thread that calls WSARecv() and keeps itself alertable.