Overlapped WSARecv() Callback Not Being Called in

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.

Answer 2

Yes, this is indeed so. APCs are processed only when thread enters an "alertable" wait state - calls either SleepEx or WaitForMultipleObjectsEx or MsgWaitForMultipleObjectsEx function.

One point that I'd like to correct you is that using OVERLAPPED's hEvent member as a placeholder for your "user" data is a bad idea. Because OS will try to set this "event" when your I/O completes.

A common way to to pass some "user" info to your callback routing is in fact using a custom structure that supersedes the OVERLAPPED, adding more members as necessary (a.k.a. OVERLAPPED_PLUS). Then your callback routing may cast OVERLAPPED to your OVERLAPPED_PLUS, there you'll see all the members.

Another point: since you're writing a COM object - you probably don't have the ability to write your own message loop, hence it may be difficult to guarantee entering the alertable wait.