|
|
Boost : |
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-11-23 17:15:19
berserker_r wrote:
> I made the test with the CVS version of boost and I still fall in the
> problem that I have reported some days ago :(
> Btw I think that a bug in the Windows API GetQueuedCompletionStatus sounds
> very strange to me because I think that implementations like this one are
> very common or I'm wrong?
Well in your case the long running operation isn't CPU bound since it
calls Sleep(). That's why I asked about it early on in this discussion,
because the only way I could reproduce the behaviour was to make it CPU
bound (e.g. an infinite loop "while (true) ;").
Anyway, you have a bug in your program which is probably not related to
your problem:
> std::string generate_response()
> {
> Sleep(10000); // It takes a lot of time to say Hello :)
> static int counter = 0;
> counter++;
> std::stringstream stream;
> stream << "<html><body><h2>Hello " << counter << "</h2></body></html>";
> return stream.str();
> }
>
> void read_handler(const boost::system::error_code &e, size_t
> bytes_transferred)
> {
> if(!e)
> {
> boost::asio::async_write(m_socket,
> boost::asio::buffer(generate_response()),
> boost::bind(&Session::write_handler, this, _1, _2));
> }
> }
The string returned by generate_response() goes out of scope before the
asynchronous operation completes. The simplest way to fix it would be to
add a std::string data member to the Session class and change
read_handler to look like this:
void read_handler(const asio::error_code &e,
size_t bytes_transferred)
{
if(!e)
{
m_message = generate_response();
boost::asio::async_write(m_socket, asio::buffer(m_message),
boost::bind(&Session::write_handler, this, _1, _2));
}
}
I fixed this in my copy before trying it, and I am unable to reproduce
the problem you described before. The subsequent accept operation works
just fine. Can you please send step-by-step instructions for how you
reproduce it with this program and exactly what behaviour you see, thanks.
Cheers,
Chris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk