On Dienstag, 29. November 2016 20:41:58 CET Christophe Henry wrote:
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.
Can you please elaborate a little on what is meant with "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.
Does this mean that Boost.Asynchronous provides realtime worst case execution time guarantees? Can you point me to the pages in the docs where those techniques are described in detail?
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost