/* Here, the order is ok because:
*
- * Short proof: only maestro adds stuff to the actors_to_run array, so the execution order of user contexts do
- * not impact its order.
+ * 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:
*
- * Long proof: actors remain sorted through an arbitrary (implicit, complex 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/).
*
- * - if there is no kill during the simulation, actors remain sorted according by their PID.
- * Rationale: This can be proved inductively.
- * Assume that actors_to_run is sorted at a beginning of one round (it is at round 0: the deployment file
- * is parsed linearly).
- * Let's show that it is still so at the end of this round.
- * - if an actor is added when being created, that's from maestro. It can be either at startup
- * time (and then in PID order), or in response to a process_create simcall. Since simcalls are handled
- * in arbitrary order (inductive hypothesis), we are fine.
- * - If an actor is added because it's getting killed, its subsequent actions shouldn't matter
- * - If an actor gets added to actors_to_run because one of their blocking action constituting the meat
- * of a simcall terminates, we're still good. Proof:
- * - You are added from ActorImpl::simcall_answer() only. When this function is called depends on the
- * resource kind (network, cpu, disk, whatever), but the same arguments hold. Let's take communications
- * as an example.
- * - For communications, this function is called from CommImpl::finish().
- * This function itself don't mess with the order since simcalls are handled in FIFO order.
- * The function is called:
- * - before the comm starts (invalid parameters, or resource already dead or whatever).
- * The order then trivial holds since maestro didn't interrupt its handling of the simcall yet
- * - because the communication failed or were canceled after startup. In this case, it's called from
- * the function we are in, by the chunk:
- * set = model->states.failed_action_set;
- * while ((synchro = extract(set)))
- * SIMIX_simcall_post((smx_synchro_t) synchro->data);
- * This order is also fixed because it depends of the order in which the surf actions were
- * added to the system, and only maestro can add stuff this way, through simcalls.
- * We thus use the inductive hypothesis once again to conclude that the order in which synchros are
- * popped out of the set does not depend on the user code's execution order.
- * - because the communication terminated. In this case, synchros are served in the order given by
- * set = model->states.done_action_set;
- * while ((synchro = extract(set)))
- * SIMIX_simcall_post((smx_synchro_t) synchro->data);
- * and the argument is very similar to the previous one.
- * So, in any case, the orders of calls to CommImpl::finish() do not depend on the order in which user
- * actors are executed.
- * So, in any cases, the orders of actors within actors_to_run do not depend on the order in which
- * user actors were executed previously.
- * So, if there is no killing in the simulation, the simulation reproducibility is not jeopardized.
- * - If there is some actor killings, the order is changed by this decision that comes from user-land
- * But this decision may not have been motivated by a situation that were different because the simulation is
- * not reproducible.
- * So, even the order change induced by the actor killing is perfectly reproducible.
- *
- * So science works, bitches [http://xkcd.com/54/].
- *
- * We could sort the actors_that_ran array completely so that we can describe the order in which simcalls are
- * handled (like "according to the PID of issuer"), but it's not mandatory (order is fixed already even if
- * unfriendly).
- * That would thus be a pure waste of time.
+ * 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.
*/
for (auto const& actor : actors_that_ran_) {
