-@section s4u_ex_actors Acting on Actors
-
-@subsection s4u_ex_actors_start Starting and stoping actors
-
- - <b>Creating actors</b>.
- @ref examples/s4u/actor-create/s4u-actor-create.cpp \n
- Most actors are started from the deployment XML file, but there is other methods.
- This example show them all.
-
- - <b>Kill actors</b>.
- @ref examples/s4u/actor-kill/s4u-actor-kill.cpp \n
- Actors can forcefully stop other actors with the @ref
- simgrid::s4u::Actor::kill() method.
-
- - <b>Controling the actor life cycle from the XML</b>.
- @ref examples/s4u/actor-lifetime/s4u-actor-lifetime.cpp
- @ref examples/s4u/actor-lifetime/s4u-actor-lifetime_d.xml
- \n
- You can specify a start time and a kill time in the deployment file.
-
- - <b>Daemonize actors</b>
- @ref examples/s4u/actor-daemon/s4u-actor-daemon.cpp \n
- Some actors may be intended to simulate daemons that run in background. This example show how to transform a regular
- actor into a daemon that will be automatically killed once the simulation is over.
-
-@subsection s4u_ex_actors_synchro Inter-actors interactions
-
- - <b>Suspend and Resume actors</b>.
- @ref examples/s4u/actor-suspend/s4u-actor-suspend.cpp \n
- Actors can be suspended and resumed during their executions
- thanks to the @ref simgrid::s4u::Actor::suspend and @ref simgrid::s4u::Actor::resume methods.
-
- - <b>Migrating Actors</b>.
- @ref examples/s4u/actor-migration/s4u-actor-migration.cpp \n
- Actors can move or be moved from a host to another with the @ref
- simgrid::s4u::this_actor::migrate() method.
-
- - <b>Waiting for the termination of an actor</b> (joining on it)
- @ref examples/s4u/actor-join/s4u-actor-join.cpp \n
- The simgrid::s4u::Actor::join() method allows to block the current
- actor until the end of the receiving actor.
-
- - <b>Yielding to other actor</b>.
- @ref examples/s4u/actor-yield/s4u-actor-yield.cpp\n
- The simgrid::s4u::this_actor::yield() function interrupts the
- execution of the current actor, leaving a chance to the other actors
- that are ready to run at this timestamp.
-
-@subsection s4u_ex_actors_replay Traces Replay as a Workload
-
-This section details how to run trace-driven simulations. It is very
-handy when you want to test an algorithm or protocol that only react
-to external events. For example, many P2P protocols react to user
-requests, but do nothing if there is no such event.
-
-In such situations, you should write your protocol in C++, and separate
-the workload that you want to play onto your protocol in a separate
-text file. Declare a function handling each type of the events in your
-trace, register them using @ref xbt_replay_action_register in your
-main, and then run the simulation.
-
-Then, you can either have one trace file containing all your events,
-or a file per simulated process: the former may be easier to work
-with, but the second is more efficient on very large traces. Check
-also the tesh files in the example directories for details.
-
- - <b>Communication replay</b>.
- @ref examples/s4u/replay-comm/s4u-replay-comm.cpp \n
- Presents a set of event handlers reproducing classical communication
- primitives (asynchronous send/receive at the moment).
-
- - <b>I/O replay</b>.
- @ref examples/s4u/replay-storage/s4u-replay-storage.cpp \n
- Presents a set of event handlers reproducing classical I/O
- primitives (open, read, close).
-
-@section s4u_ex_synchro Classical synchronization objects