X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/6e02d3033625ed752857b621b3174efba3f8911d..77b12b606f33a679ef2d13eeb2b9f208e2f52bc0:/docs/source/app_s4u.rst

diff --git a/docs/source/app_s4u.rst b/docs/source/app_s4u.rst
index 46cc216d9c..c4dbd414e8 100644
--- a/docs/source/app_s4u.rst
+++ b/docs/source/app_s4u.rst
@@ -20,7 +20,7 @@ with the full power of C++. This is the preferred interface to describe
 abstract algorithms in the domains of Cloud, P2P, HPC, IoT, and similar
 settings.
 
-Currently (v3.21), S4U is definitely the way to go for long-term
+Since v3.20 (June 2018), S4U is definitely the way to go for long-term
 projects. It is feature complete, but may still evolve slightly in the
 future releases. It can already be used to do everything that can be
 done in SimGrid, but you may have to adapt your code in future
@@ -56,7 +56,10 @@ synchronization mechanisms** such as |API_s4u_Barrier|_, |API_s4u_Semaphore|_,
 Each actor is located on a simulated |API_s4u_Host|_. Each host is located
 itself in a |API_s4u_NetZone|_, that knows the networking path between one
 resource to another. Each NetZone is included in another one, forming
-a tree of NetZones which root zone contains the whole platform.
+a tree of NetZones which root zone contains the whole platform. The
+actors can also be located on a |API_s4U_VirtualMachine|_ that may
+restrict the activities it contains to a limited amount of cores.
+Virtual machines can also be migrated between hosts.
 
 The :ref:`simgrid::s4u::this_actor <API_s4u_this_actor>` namespace
 provides many helper functions to simplify the code of actors.
@@ -116,8 +119,7 @@ provides many helper functions to simplify the code of actors.
 .. |API_s4u_Storages| replace:: **Storages**
 .. _API_s4u_Storages: #s4u-storage
 
-.. |API_s4u_VirtualMachines| replace:: **VirtualMachines**
-.. _API_s4u_VirtualMachines: #s4u-virtualmachine
+.. |API_s4u_VirtualMachine| replace:: **VirtualMachines**
 
 .. |API_s4u_Host| replace:: **Host**
 
@@ -329,6 +331,13 @@ posted to that mailbox will start as soon as possible, and the data
 will already be there on the receiver host when the receiver actor
 posts its :cpp:func:`get() <simgrid::s4u::Mailbox::get()>`
 
+Note that being permanent receivers of a mailbox prevents actors to be
+garbage-collected. If your simulation creates many short-lived actors
+that marked as permanent receiver, you should call
+``mailbox->set_receiver(nullptr)`` by the end of the actors so that their
+memory gets properly reclaimed. This call should be at the end of the
+actor's function, not in a on_exit callback.
+
 Memory Management
 *****************
 
@@ -385,6 +394,8 @@ s4u::Actor
 
 .. doxygentypedef:: ActorPtr
 
+.. doxygentypedef:: aid_t
+
 .. doxygenclass:: simgrid::s4u::Actor
    :members:
    :protected-members: