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.