Comments on Thinking Asynchronously in C++: Composed operations, coroutines and code makeover

Note that try/catch followed by a yield on the nex...

2010-03-31T14:25:28.054+11:00

Note that try/catch followed by a yield on the next line doesn't do quite the right thing (see new post). However, you could probably write:

yield try
{
...
}
catch (exception& e)
{
...
}

However, in regards to exception handling, the yie...

2010-02-28T20:50:24.802+11:00

However, in regards to exception handling, the yield function can become standalone so you can do the async call (within a try/catch) before the yield, then call yield on the next line (followed by ; or {}).

I really like your stackless coroutine implementat...

2009-11-28T07:23:04.163+11:00

I really like your stackless coroutine implementation, there is only one thing which makes me a bit nervous - exception handling inside coroutine body. It's impossible to wrap "yield" call with try...catch block(you'll get "jump to case label enters try block" error) which is really disturbing.

starfish, you're right but you can't pass ...

2009-11-17T03:34:37.886+11:00

starfish, you're right but you can't pass the lambda any initialization variables (use []), you'd have to bind those to onAccept when passed to async_accept.

2009-11-15T02:08:21.725+11:00

This comment has been removed by a blog administrator.

Btw, I think the the lambda reference problem disc...

2009-10-26T04:55:39.525+11:00

Btw, I think the the lambda reference problem discussed above can be solved by making the onAccept static.

Hello, I think I've found a bug in asio, compi...

2009-10-26T04:37:53.628+11:00

Hello, I think I've found a bug in asio, compiled for win64. The following code compiles, but generates an access violation when run:

std::string message = "This is a server message!";
boost::asio::buffer (message);

Hey Chris! Thanks for the response. Now I understa...

2009-09-08T16:37:10.753+10:00

Hey Chris! Thanks for the response. Now I understand what you mean. You're right about the problem calling itself. Actually you can call the lambda from itself fine, even when you leave the scope. You just can't pass it as an argument and have it called from somewhere else. Which is why my last example worked, I put the h1 = h2 part to show it works when the scope ends, but I didn't pass it to a function, like you would with async_accept - it would fail from within io_service's run().

Here's async_echo:

//template <typename Handler>
void async_echo(
tcp::socket& socket,
mutable_buffer working_buffer,
//Handler handler,
boost::function<void()> handler,
error_code ec = error_code(),
size_t length = 0)
{
socket.async_read_some(buffer(working_buffer), [&socket, &working_buffer, &length, handler](error_code const& error, int total)
{
async_write(socket, buffer(working_buffer, length), [&socket, &working_buffer, handler](error_code const& error, int total)
{
handler();
});
});
}

Apparently there's a known bug with lambdas atm that they don't work with templated dependent types. I'm sure they'll fix that. Just to show it works though I used boost::function (or std::function).

So yeah, you can't have a gimmick all-in-one lambda server, you need to separate your loop function.

I had an example finished but it segfauls due to that lambda glitch. You think they'll fix these things? (2 big issues)

Thanks :)

In your snippet, both of these places: h2(); &l...

2009-09-07T14:50:43.862+10:00

In your snippet, both of these places:

h2(); <--- here
} //end scope

h1(); <--- and here

will perform "h1 = h2;". Obviously you need to do some additional housekeeping inside the lambda to make this work.

I'd be very interested to see a more fully worked example for an async_accept loop using this approach. And, for bonus points, whether you can do a lambda-based implementation of the async_echo composed operation (working as shown in the original blog post).

Oh right, I gotcha. A lambda can't copy itself...

2009-09-06T11:51:46.127+10:00

Oh right, I gotcha. A lambda can't copy itself by value in the initializer list (only by reference), but from within itself it can copy itself can't it? Which is where you would be calling the async operation (passing itself, ie. a copy). How would there be a danging reference then?

std::function<void()> h1;

{ //begin scope
std::function<void()> h2 = [&]()
{
cout << "Hello world!" << endl;

h1 = h2;
};

h2();
} //end scope

h1();

So I might not be understanding because I don't see what's wrong with that. h2 is the lambda, h1 is the async_accept/etc argument. Either way I imagine there would be some additional overhead using lambdas. Although I guess that's the case either way.

This code captures the lambda variable ("onAc...

2009-09-06T09:29:12.544+10:00

This code captures the lambda variable ("onAccept") by reference. This means you will have a dangling reference in the completion handler as soon as you leave the scope where the async operation was started.

For it to work, you need to store a copy of the lambda object, but a lambda cannot capture a copy of itself.

Oh, I personally find lambdas more readable, since...

2009-09-06T01:38:04.217+10:00

Oh, I personally find lambdas more readable, since they are akin to inline functions, and closures of other languages. If you declare them by name, they appear almost exactly the same as normal functions.

What do you mean lambdas can't perform loops of asynchronous operations? Do you mean:

tcp::socket socket(io_service_);
tcp::acceptor acceptor(io_service_);

auto onAccept = [&](tcp::socket& socket, error_code ec)
{
handler(ec);

acceptor.async_accept(socket, onAccept);
};

acceptor.async_accept(socket, onAccept);

Same as how your coroutine example goes from top to bottom over and over (looping). I don't think any form of recursion (or "loops") work at the moment, but it's in the standard proposal.

Still, there's a few caveats with c++0x lambdas. I'm just trying to understand the benefits of coroutines in comparison.

In my opinion, coroutines are more readable. More ...

2009-09-05T22:22:24.374+10:00

In my opinion, coroutines are more readable. More important, however, is that they are capable of complex control flow, such as loops. Lambdas can't do loops of async operations within a single function.

Lambdas ARE code liposuction, but if your compiler...

2009-09-05T21:47:46.531+10:00

Lambdas ARE code liposuction, but if your compiler is capable of lambdas, why wouldn't you just use those instead of coroutines? ie. something like...

socket.async_read_some(buffer(working_buffer), [&](tcp::socket& socket, error_code ec)
{
async_write(socket, buffer(working_buffer, length), [&](tcp::socket& socket, error_code ec)
{
handler(ec);
});
});

Understood. Thanks Chris. Asio rulez!

2009-08-14T14:17:37.013+10:00

Understood. Thanks Chris. Asio rulez!

The proposed boost::coroutine library provides sta...

2009-08-14T10:55:52.739+10:00

The proposed boost::coroutine library provides stackful coroutines (vs the stackless ones I showed).

The advantage of having a stack is that you can yield from a nested function, which means you can layer non-async-aware APIs (e.g. a boost.spirit parser) over the top of async calls.

However, one of the disadvantages is that you have a stack :)

You can't transparently implement composed operations using stackful coroutines because you have to pass the coroutine's "self" reference to the function. (Well actually you could do it by creating a new coroutine stack for each composed operation, but that could be quite expensive.)

What do you think about this boost::coroutine? ht...

2009-08-14T07:31:50.311+10:00

What do you think about this boost::coroutine?

http://www.crystalclearsoftware.com/soc/coroutine

Cool!

2009-08-13T11:44:57.588+10:00

Cool!