Hi,<br><br>I&#39;m having trouble with the io_service destructor never completing. The application I am working on uses one worker thread to handle all actual work to be done including communication on a socket in handler functions posted to the asio queue and another thread to handle the gui of the application.<br>
<br>At a certain point in time the program decides that it has nothing more to do and calls the io_service::stop function. Shortly thereafter the thread returns from its call to the io_service::run function. The next thing that happens is that the io_service object goes out of scope and thus the io_service destructor is called. After this the thread signals that it is finished and the application exits.<br>
<br>The problem I am seeing is that the destructor never finishes. Or actually, a customer sees this problem, but I have not been able to reproduce this so all the information I have comes from adding (excessive) logging in the boost source.<br>
<br>The io_service destructor loops through all services and calls shutdown_service on each one. The win_iocp_io_service handles this call by entering a while loop that should complete when the outstanding_work_ variable becomes zero. Inside the loop, there is a call to GetQueuedCompletionStatus to dequeue a completion packet, which is then tested to see if it contains a valid operation that is then destroyed and the outstanding_work_ variable is decremented.<br>
<br>In all the runs I have made, outstanding_work_ is initially 1 when the shutdown_service function is entered. The first and second calls to GetQueuedCompletionStatus come back immediately and the second results in the outstanding_work_ variable being decremented and the loop exits. Everything is fine.<br>
<br>At the customer location however, the second call times out instead of completing immediately and it continues to do so for subsequent loop iterations until the application is forcibly closed. There is only one of our customers who gets this problem. The customer runs Windows XP SP3, but I have failed to reproduce this on my own XP test machine.<br>
<br>We have tried both Boost version 1.43 and version 1.40 with the same result. In both cases, the customer has the problem but I cannot reproduce it. The asio behavior has changed somewhat between the versions and the description of the problem above is with version 1.43.<br>
<br>Does anyone have any idea of what may be going on? Any hints or tips are appreciated! Could we be using asio wrong in some way that could cause this, but we&#39;re just lucky most of the time? The customer may be running in a virtual machine, could this affect io completion ports in a way that could be problematic for asio?<br>
<br>Cheers,<br>Ragnar<br><br>