![]() |
We have had roughly 800 commits since the last release and we have closed approximately 80 tickets (bugs, feature requests, etc.).
hpx::lcos::packaged_task
<>
to hpx::lcos::packaged_action
<>
to reflect the semantic differences
to a packaged_task as defined by the C++11
Standard.
hpx::thread
which is compliant to the C++11 std::thread type except that it (purely
locally) represents an HPX thread. This new type
does not expose any of the remote capabilities of the underlying HPX-thread
implementation.
hpx::lcos::future
<>
is now compliant to the C++11
std::future<> type. This type can be used to synchronize both,
local and remote operations. In both cases the control flow will 'return'
to the future in order to trigger any continuation.
hpx::lcos::local::promise
<>
and hpx::lcos::local::packaged_task
<>
are now compliant to the C++11
std::promise<>
and std::packaged_task<>
types. These can be used to create a future representing local work
only. Use the types hpx::lcos::promise
<>
and hpx::lcos::packaged_action
<>
to wrap any (possibly remote)
action into a future.
hpx::thread
and hpx::lcos::future
<>
are now cancelable.
hpx::lcos::future
<>
's. The member function hpx::lcos::future::when
()
permits futures to be sequentially
composed. The helper functions hpx::wait_all
,
hpx::wait_any
, and
hpx::wait_n
can be used
to wait for more than one future at a time.
hpx::apply
()
and hpx::async
()
as the preferred way of creating
(or invoking) any deferred work. These functions are usable with various
types of functions, function objects, and actions and provide a uniform
way to spawn deferred tasks.
hpx::util::bind
to (partially) bind local functions and function objects, and also
actions. Remote bound actions can have placeholders as well.
hpx::actions::forwarding_continuation
is an example of how the user can write is own types of continuations.
It can be used to execute any function as an continuation of a particular
action.
hpx::apply
()
, hpx::async
()
, or using the operator()
implemented on actions. Actions themselves
can now be cheaply instantiated as they do not have any members anymore.
hpx::util::bind
()
by passing an action instance as
the first argument.
A minimal HPX program now looks like this:
#include <hpx/hpx_init.hpp> int hpx_main() { return hpx::finalize(); } int main() { return hpx::init(); }
This removes the immediate dependency on the Boost.Program Options library.
![]() |
Note |
---|---|
This minimal version of an HPX program does not
support any of the default command line arguments (such as --help, or
command line options related to PBS). It is suggested to always pass
|
In order to support those, but still not to depend on Boost.Program Options, the minimal program can be written as:
#include <hpx/hpx_init.hpp> // The arguments for hpx_main can be left off, which very similar to the // behavior of `main()` as defined by C++. int hpx_main(int argc, char* argv[]) { return hpx::finalize(); } int main(int argc, char* argv[]) { return hpx::init(argc, argv); }
hpx::components::binpacking_factory
which is equivalent to the existing hpx::components::distributing_factory
component, except that it equalizes the overall population of the components
to create. It exposes two factory methods, one based on the number
of existing instances of the component type to create, and one based
on an arbitrary performance counter which will be queried for all relevant
localities.
hpx::get_locality_id
()
, hpx::get_host_name
()
, hpx::get_process_id
()
, hpx::get_function_name
()
, hpx::get_file_name
()
, hpx::get_line_number
()
, hpx::get_os_thread
()
, hpx::get_thread_id
()
, and hpx::get_thread_description
()
.
Here is a list of the important tickets we closed for this release:
handle_gid<>
should raise an exception
hpx::util::function
s
to be registered in the AGAS symbolic namespace
boost::bind
boost::function
hpx::util::function
to actions
hpx::function
with hpx::util::function
handle_gid<>
support for hpx::util::function
*_c_cache
code
throws an exception
if the queried GID is not in the local cache
hpx::init
()
and hpx_main() should not depend
on program_options
hpx::lcos::wait
should work with dataflows and arbitrary classes meeting the future
interface
hpx::lcos::wait
make install
on an out-of-tree application
is broken
locality_results
is not a member of hpx::components::server
traits::*result
wrt std::vector<id_type>