Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
kill an unused function
[simgrid.git] / src / simix / smx_global.cpp
index ad2d351..adcb65e 100644 (file)
@@ -1,4 +1,4 @@
-/* Copyright (c) 2007-2017. The SimGrid Team. All rights reserved.          */
+/* Copyright (c) 2007-2018. The SimGrid Team. All rights reserved.          */
 
 /* This program is free software; you can redistribute it and/or modify it
  * under the terms of the license (GNU LGPL) which comes with this package. */
@@ -11,7 +11,6 @@
 #include <csignal> /* Signal handling */
 #include <cstdlib>
 
-#include <xbt/algorithm.hpp>
 #include <xbt/functional.hpp>
 #include <xbt/utility.hpp>
 
@@ -69,7 +68,7 @@ public:
   s_smx_timer_t(double date, simgrid::xbt::Task<void()> callback) : date(date), callback(std::move(callback)) {}
 };
 
-void (*SMPI_switch_data_segment)(int) = nullptr;
+void (*SMPI_switch_data_segment)(simgrid::s4u::ActorPtr) = nullptr;
 
 int _sg_do_verbose_exit = 1;
 static void inthandler(int)
@@ -170,21 +169,16 @@ static void kill_process(smx_actor_t process)
   SIMIX_process_kill(process, nullptr);
 }
 
-static std::function<void()> maestro_code;
 
 namespace simgrid {
 namespace simix {
 
 simgrid::xbt::signal<void()> onDeadlock;
 
-XBT_PUBLIC(void) set_maestro(std::function<void()> code)
-{
-  maestro_code = std::move(code);
-}
-
 }
 }
 
+static std::function<void()> maestro_code;
 void SIMIX_set_maestro(void (*code)(void*), void* data)
 {
 #ifdef _WIN32
@@ -196,9 +190,6 @@ void SIMIX_set_maestro(void (*code)(void*), void* data)
 /**
  * \ingroup SIMIX_API
  * \brief Initialize SIMIX internal data.
- *
- * \param argc Argc
- * \param argv Argv
  */
 void SIMIX_global_init(int *argc, char **argv)
 {
@@ -210,9 +201,6 @@ void SIMIX_global_init(int *argc, char **argv)
 
   if (not simix_global) {
     simix_global = std::unique_ptr<simgrid::simix::Global>(new simgrid::simix::Global());
-
-    simgrid::simix::ActorImpl proc;
-    simix_global->process_to_destroy = xbt_swag_new(xbt_swag_offset(proc, destroy_hookup));
     simix_global->maestro_process = nullptr;
     simix_global->create_process_function = &SIMIX_process_create;
     simix_global->kill_process_function = &kill_process;
@@ -224,7 +212,7 @@ void SIMIX_global_init(int *argc, char **argv)
 
     // Either create a new context with maestro or create
     // a context object with the current context mestro):
-    simgrid::simix::create_maestro(maestro_code);
+    simgrid::kernel::actor::create_maestro(maestro_code);
 
     /* Prepare to display some more info when dying on Ctrl-C pressing */
     signal(SIGINT, inthandler);
@@ -286,7 +274,7 @@ void SIMIX_clean()
 #endif
 
   /* Kill all processes (but maestro) */
-  SIMIX_process_killall(simix_global->maestro_process, 1);
+  SIMIX_process_killall(simix_global->maestro_process);
   SIMIX_context_runall();
   SIMIX_process_empty_trash();
 
@@ -300,14 +288,14 @@ void SIMIX_clean()
   /* Free the remaining data structures */
   simix_global->process_to_run.clear();
   simix_global->process_that_ran.clear();
-  xbt_swag_free(simix_global->process_to_destroy);
+  simix_global->process_to_destroy.clear();
   simix_global->process_list.clear();
-  simix_global->process_to_destroy = nullptr;
 
   xbt_os_mutex_destroy(simix_global->mutex);
   simix_global->mutex = nullptr;
 #if SIMGRID_HAVE_MC
   xbt_dynar_free(&simix_global->actors_vector);
+  xbt_dynar_free(&simix_global->dead_actors_vector);
 #endif
 
   /* Let's free maestro now */
@@ -343,9 +331,9 @@ double SIMIX_get_clock()
 /** Wake up all processes waiting for a Surf action to finish */
 static void SIMIX_wake_processes()
 {
-  surf_action_t action;
-
   for (auto const& model : *all_existing_models) {
+    simgrid::kernel::resource::Action* action;
+
     XBT_DEBUG("Handling the processes whose action failed (if any)");
     while ((action = surf_model_extract_failed_action_set(model))) {
       XBT_DEBUG("   Handling Action %p",action);
@@ -438,13 +426,15 @@ void SIMIX_run()
 
       /* Here, the order is ok because:
        *
-       *   Short proof: only maestro adds stuff to the process_to_run array, so the execution order of user contexts do not impact its order.
+       *   Short proof: only maestro adds stuff to the process_to_run array, so the execution order of user contexts do
+       *   not impact its order.
        *
        *   Long proof: processes remain sorted through an arbitrary (implicit, complex but fixed) order in all cases.
        *
        *   - if there is no kill during the simulation, processes remain sorted according by their PID.
-       *     rational: This can be proved inductively.
-       *        Assume that process_to_run is sorted at a beginning of one round (it is at round 0: the deployment file is parsed linearly).
+       *     Rationale: This can be proved inductively.
+       *        Assume that process_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 a process 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
@@ -453,37 +443,42 @@ void SIMIX_run()
        *        - If a process gets added to process_to_run because one of their blocking action constituting the meat
        *          of a simcall terminates, we're still good. Proof:
        *          - You are added from SIMIX_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.
+       *            kind (network, cpu, disk, whatever), but the same arguments hold. Let's take communications as an
+       *            example.
        *          - For communications, this function is called from SIMIX_comm_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:
+       *            - 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 = xbt_swag_extract(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
-       *              poped out of the swag does not depend on the user code's execution order.
+       *              poped 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 = xbt_swag_extract(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 SIMIX_comm_finish() do not depend on the order in which user processes are executed.
-       *          So, in any cases, the orders of processes within process_to_run do not depend on the order in which user processes were executed previously.
+       *            So, in any case, the orders of calls to SIMIX_comm_finish() do not depend on the order in which user
+       *            processes are executed.
+       *          So, in any cases, the orders of processes within process_to_run do not depend on the order in which
+       *          user processes were executed previously.
        *     So, if there is no killing in the simulation, the simulation reproducibility is not jeopardized.
        *   - If there is some process 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.
+       *     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 process killing is perfectly reproducible.
        *
        *   So science works, bitches [http://xkcd.com/54/].
        *
-       *   We could sort the process_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).
+       *   We could sort the process_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.
        */
 
@@ -550,6 +545,7 @@ void SIMIX_run()
 
     XBT_CRITICAL("Oops ! Deadlock or code not perfectly clean.");
     SIMIX_display_process_status();
+    simgrid::s4u::onDeadlock();
     xbt_abort();
   }
   simgrid::s4u::onSimulationEnd();
@@ -566,7 +562,7 @@ void SIMIX_run()
  */
 smx_timer_t SIMIX_timer_set(double date, void (*callback)(void*), void *arg)
 {
-  smx_timer_t timer = new s_smx_timer_t(date, [callback, arg]() { callback(arg); });
+  smx_timer_t timer = new s_smx_timer_t(date, simgrid::xbt::makeTask([callback, arg]() { callback(arg); }));
   timer->handle_    = simix_timers.emplace(std::make_pair(date, timer));
   return timer;
 }
@@ -657,12 +653,12 @@ void SIMIX_display_process_status()
       if (boost::dynamic_pointer_cast<simgrid::kernel::activity::IoImpl>(process->waiting_synchro) != nullptr)
         synchro_description = "I/O";
 
-      XBT_INFO("Process %lu (%s@%s): waiting for %s synchro %p (%s) in state %d to finish", process->pid,
+      XBT_INFO("Process %ld (%s@%s): waiting for %s synchro %p (%s) in state %d to finish", process->pid,
                process->getCname(), process->host->getCname(), synchro_description, process->waiting_synchro.get(),
                process->waiting_synchro->name.c_str(), (int)process->waiting_synchro->state);
     }
     else {
-      XBT_INFO("Process %lu (%s@%s)", process->pid, process->getCname(), process->host->getCname());
+      XBT_INFO("Process %ld (%s@%s)", process->pid, process->getCname(), process->host->getCname());
     }
   }
 }