Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2016-11-29 14:41:58
>boost.asynchronous looks to have many of the same features/functionality
as HPX.
>Can I ask why you chose to reimplement futures/lightweight thread
pools/parallel STL/etc,
>rather than working on improving HPX to suit your needs?
I don't think the libraries have the same goals (or at least it seems to me
so). Asynchronous is first of all an architecture tool focusing on
organizing a whole application into thread worlds.
The libraries also do not have the same design / tradeoffs. Asynchronous
can make use of futures but encourages callbacks and tries to make these as
safe as possible. The goal is to be as asynchronous (meaning non-blocking)
as possible.
It is no coincidence that I'm also the author of Boost.MSM. The encouraged
design is a whole lot of state machines, each in its own thread (possibly
sharing a thread), sending tasks to threadpools, TCP connections, etc. and
waiting for callbacks. Future-based designs do not mix well with state
machines' run-to-completion.
The reason for the non-blocking focus is that I'm using the library at work
in an industrial 24/7 application. When working on the production line,
blocking is a disaster. If an algorithm goes astray, or simply takes longer
than usually, blocking the production line results in huge costs. Crashes
due to races also. Asynchronous provides ways to avoid both.
>JB
>Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC
Guys" :) .
No hard feeling. I'm grateful for participation and the chance to explain
the underlying ideas of the library.
Thanks,
Christophe