Re: [boost] Mixing async/sync code thanks to boost::context

Subject: Re: [boost] Mixing async/sync code thanks to boost::context
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-12-11 23:35:19

On 12/12/2018 10:30, Christophe Bailly wrote:
> I am new in this mailing list, I hope this is the right list to post my
> issue.

If you have a question about using Boost libraries, then it belongs on 
the Boost-Users list.  This list is for development of Boost libraries.

> Why isn't it possible so far to do this without changing all the functions
> ?? I find this really ugly, this is really difficult to make a good design.

It's inherent in the async/await design -- async functions must await to 
"block", they can't call traditional thread-blocking functions otherwise 
they prevent forward progress of other async tasks.  (Sometimes this may 
appear to be harmless as they can sometimes use other threads to 
progress, but it's still incorrect code.)

Boost.Context and Boost.Coroutine are the same way -- you need to 
explicitly yield rather than blocking the thread some other way.

Async functions can only call other async functions or sync functions 
that are expected to complete immediately (or with only CPU-bound work).

I remember recently reading someone making an analogy between this and 
const functions only being able to call other const functions, or (in 
some other language that I don't recall) I/O functions being able to 
call non-I/O functions but not the reverse.  It's just the way it works.

> In my example, the "library" is represented by the function calculate which
> is synchronous. It calls a function call_server which simulates the call to
> a server, in fact it will just wait for 5 seconds but in a asynchronous
> way.
> The main function will do a computation in parallel while the server will
> be called. You will find the code at the end of the mail.
> 
> This sounds too good to be true but in this case, where did I miss
> something ? I haven't implemented a socket with a select but this would
> work, right ?

If you're looking for an asynchronous reactor library, then look at 
Boost.Asio.  Or Boost.Fiber for a slightly different solution space.

These already support futures and coroutines.