Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk