Steve,
I've found the issue and a workaround.
The following fragment of code uses a very common coding pattern. I'm using Concurrency namespace here.
I posted this issue to http://stackoverflow.com/questions/24341792/c-not-understanding-object-destruction-rules
Your above post actually helped me to find the issue. Using std::queue is wrong as it isn't thread safe. However, I eventually realized that your example worked because it never created a temporary request variable.
Robert
I've found the issue and a workaround.
The following fragment of code uses a very common coding pattern. I'm using Concurrency namespace here.
web::http::http_request request;
while (cq.try_pop(request))
request.reply(web::http::status_codes::ServiceUnavailable).wait();
However, for purposes of the SDK, it's wrong. The issue is that after the while() completes, request still holds an object which causes close().wait() to hang. Instead, the following code causes request to go out of scope and solves the issue. I'm using boost::lockfree namespace here.while (!queue.empty())
{
web::http::http_request request;
if (queue.pop(request))
request.reply(web::http::status_codes::ServiceUnavailable).wait();
}
I'm speculating there's some issue with http_request object's copy or assignment methods that contributes to the issue. It's not clear to me 1) that the first example should create a hang. 2) the issue is so darn hard to see, even for an expert, that something should be done to avoid it from happening such as a compiler or runtime message, or some change to copy or assignment methods.I posted this issue to http://stackoverflow.com/questions/24341792/c-not-understanding-object-destruction-rules
Your above post actually helped me to find the issue. Using std::queue is wrong as it isn't thread safe. However, I eventually realized that your example worked because it never created a temporary request variable.
Robert