Basic asynchronous communications
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Illustrates how to have non-blocking communications, that are communications running in the background leaving the process
+Illustrates how to have non-blocking communications, that are communications running in the background leaving the process
free to do something else during their completion.
.. tabs::
Dealing with network failures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This examples shows how to survive to network exceptions that occur when a link is turned off. In this case, any blocking operation
-such as ``put``, ``get`` or ``wait`` will raise an exception that you can catch and react to. See also :ref:`howto_churn` and
-:ref:`this example <s4u_ex_platform_state_profile>` on how to attach a state profile to hosts and react to execution failures.
+This examples shows how to survive to network exceptions that occur when a link is turned off, or when the actor with whom
+you communicate fails because its host is turned off. In this case, any blocking operation such as ``put``, ``get`` or
+``wait`` will raise an exception that you can catch and react to. See also :ref:`howto_churn`,
+:ref:`this example <s4u_ex_platform_state_profile>` on how to attach a state profile to hosts and
+:ref:`that example <s4u_ex_exec_failure>` on how to react to host failures.
.. tabs::
.. example-tab:: examples/c/energy-exec-ptask/energy-exec-ptask.c
+.. _s4u_ex_exec_failure:
+
+Dealing with host failures
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This examples shows how to survive to host failure exceptions that occur when an host is turned off. The actor do not get notified when the host
+on which they run is turned off: they are just terminated in this case, and their ``on_exit()`` callback gets executed. For remote executions on
+failing hosts however, any blocking operation such as ``exec`` or ``wait`` will raise an exception that you can catch and react to. See also
+:ref:`howto_churn`,
+:ref:`this example <s4u_ex_platform_state_profile>` on how to attach a state profile to hosts, and
+:ref:`that example <s4u_ex_comm_failure>` on how to react to networ failures.
+
+.. tabs::
+
+ .. example-tab:: examples/cpp/exec-failure/s4u-exec-failure.cpp
+
.. _s4u_ex_dvfs:
DVFS and pstates
^^^^^^^^^^^^^^^^^^^^^^^^^
Shows how to specify when the resources must be turned off and on again, and how to react to such
-failures in your code. See also :ref:`howto_churn` and :ref:`this example <s4u_ex_comm_failure>`
-on how to react to communication failures.
+failures in your code. See also :ref:`howto_churn`,
+:ref:`this example <s4u_ex_comm_failure>` on how to react to communication failures, and
+:ref:`that example <s4u_ex_exec_failure>` on how to react to host failures.
.. tabs::
Modifying the platform
----------------------
-Serializing communications
+Serializing communications
^^^^^^^^^^^^^^^^^^^^^^^^^^
This example shows how to limit the amount of communications going through a given link.
It is very similar to the other asynchronous communication examples, but messages get serialized by the platform.
Without this call to ``Link::set_concurrency_limit(2)``, all messages would be received at the exact same timestamp since
-they are initiated at the same instant and are of the same size. But with this extra configuration to the link, at most 2
+they are initiated at the same instant and are of the same size. But with this extra configuration to the link, at most 2
messages can travel through the link at the same time.
.. tabs::
