Using Boost Asio in Windows

Hi all:

Using MS Visual Studio 2008 C++ for Windows 32 (XP brand), I try to construct a POP3 client managed from a modeless dialog box.

As a first step I create a persistent object -say pop3- with all that Boost.asio stuff to do asynchronous connections, in the WM_INITDIALOG message in the dialog-box-procedure. Some like:

case WM_INITDIALOG:
return (iniPop3Dlg (hDlg, lParam));

Here we assume that iniPop3Dlg() create the pop3 heap object -say pointed out by pop3p-. Then connect with the remote server, and initiate a session with the client’s id and password (USER and PASS commands). Here we assume that the server is in TRANSACTION state.

Then, in response to some user input, the dialog-box-procedure, call the appropriate function. Say:

case IDS_TOTAL: // get how many emails in the server
total (pop3p);
return FALSE;
case IDS_DETAIL: // get date, sender and subject for each email in the server
detail (pop3p);
return FALSE;


Note that total() uses the POP3’s STAT command to get how many emails in the server, while detail() uses two commands consecutively; first STAT to get the total and then a loop with the GET command to retrieve the content of each message.

As an aside: detail() and total() share the same subroutines -the STAT handle routine-, and when finished, both leaves the session as-is. That is, without closing the connection; the socket remains opened an the server in TRANSACTION state.

When any option is selected by the first time, the things run as expected, obtaining the desired results. But when making the second chance, the connection hangs.

A closer inspection show that the first time that is used the statement

socket_.get_io_service().run();

It never ends.

Note that all asynchronous wirte an read routines uses the same io_service, and the

socket_.get_io_service().reset();

Sentence prior to any run()

Note also that all R/W operations also uses the same timer, who is reseted to cero wait afther each operation is completed:

dTimer_.expires_from_now (boost::posix_time::seconds(0));

I suspect that the problem is in the io_service or in the timer, and the fact that subsequent execution occurs in a different load of the routine.

As a first approach to mi problem, I hope that someone would bring some light in it, prior to a more detailed exposition of the -very few and simple- routines involved.