[Boost-users] Help needed with successive calls to Asio routines using the plain old Windows API

Subject: [Boost-users] Help needed with successive calls to Asio routines using the plain old Windows API
From: Adolfo Jimenez (adolfojmillan_at_[hidden])
Date: 2011-02-24 05:21:47

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, in the  WM_INITDIALOG message in the dialog-box-procedure,
I create a persistent object -say pop3- with all that Boost.asio stuff to do
asynchronous connections.  Some like:

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

Here we assume that iniPop3Dlg() create the pop3 heap object -say pointed
out by pop3p-, and then, connect with the remote server and  initiate a
session with the client’s id and password (USER and PASS commands). After
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 in the second chance, the first  time that
is use the statement

     socket_.get_io_service().run();

It never return.

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

     socket_.get_io_service().reset();

sentence prior to any io_service.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 executions 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- Asio routines involved.