- /* answer sequentially and in a fixed arbitrary order all the simcalls that were issued during that sub-round */
-
- /* WARNING, the order *must* be fixed or you'll jeopardize the simulation reproducibility (see RR-7653) */
-
- /* Here, the order is ok because:
- *
- * Only maestro adds stuff to the actors_to_run array, so the execution order of user contexts do not impact its order.
- *
- * In addition, actors remain sorted through an arbitrary but fixed order in all cases:
- *
- * - If there is no killing during the simulation, actors remain sorted according by their PID.
- * - Killer actors are moved to the end of the scheduling round (to let victims finish their simcall before dying), but
- * (1) this decision of killing is reproducible because the simulation was reproducible until then
- * (2) this reordering introduces no reproducibility hazard in the subsequent simulation.
- * Even the order change induced by the actor killing is perfectly reproducible.
- *
- * So the array order is implicit and somewhat complex, but fixed and reproducible (science works, http://xkcd.com/54/).
- *
- * We could manually sort the actors_that_ran array so that simcalls are handled in an easy to predict order
- * (e.g. "according to the PID of issuer"), but it's not mandatory for the simulation soundness and reproducibility,
- * and would thus be a pure waste of time.
+ /* answer sequentially and in a fixed arbitrary order all the simcalls that were issued during that sub-round.
+ * The order must be fixed for the simulation to be reproducible (see RR-7653). It's OK here because only maestro
+ * changes the list. Killer actors are moved to the end to let victims finish their simcall before dying, but
+ * the order remains reproducible (even if arbitrarily). No need to sort the vector for sake of reproducibility.