X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/ecd5f7562caf1d443bf22788fa5f4fac408776ec..b9625f82f86db0674e911887addce45dca31b57f:/doc/doxygen/uhood.doc

diff --git a/doc/doxygen/uhood.doc b/doc/doxygen/uhood.doc
index 67632a5d26..747aa5ee76 100644
--- a/doc/doxygen/uhood.doc
+++ b/doc/doxygen/uhood.doc
@@ -1,13 +1,13 @@
 /*! @page uhood Under the Hood
 
-\tableofcontents
+@tableofcontents
 
 TBD
 
  - Simulation Loop, LMM, sharing -> papers
  - Context Switching, privatization -> papers
 
-\section simgrid_uhood_s4u S4U
+@section simgrid_uhood_s4u S4U
 
 S4U classes are designed to be user process interfaces to Maestro resources.
 We provide an uniform interface to them:
@@ -24,13 +24,13 @@ We provide an uniform interface to them:
 - the Maestro object and the corresponding S4U object have the same lifetime
   (and share the same reference count).
 
-The ability to manipulate thge objects thought pointers and have the ability
+The ability to manipulate the objects through pointers and have the ability
 to use explicit reference count management is useful for creating C wrappers
 to the S4U and should play nicely with other language bindings (such as
 SWIG-based ones).
 
 Some objects currently live for the whole duration of the simulation and do
-not have refertence counts. We still provide dummy `intrusive_ptr_add_ref(p)`,
+not have reference counts. We still provide dummy `intrusive_ptr_add_ref(p)`,
 `intrusive_ptr_release(p)` and `FooPtr` for consistency.
 
 In many cases, we try to have a API which is consistent with the API or
@@ -129,9 +129,9 @@ void SIMIX_process_unref(smx_process_t process)
 }
 ~~~
 
-\section simgrid_uhood_async Asynchronous operations
+@section simgrid_uhood_async Asynchronous operations
 
-\subsection simgrid_uhood_futures Futures
+@subsection simgrid_uhood_futures Futures
 
 The `simgrid::kernel::Future` class has been added to SimGrid as an abstraction
 to represent asynchronous operations in the SimGrid maestro. Its API is based
@@ -181,9 +181,7 @@ simgrid::kernel::Future<void> kernel_wait_until(double date)
 {
   auto promise = std::make_shared<simgrid::kernel::Promise<void>>();
   auto future = promise->get_future();
-  SIMIX_timer_set(date, [promise] {
-    promise->set_value();
-  });
+  simgrid::simix::Timer::set(date, [promise] { promise->set_value(); });
   return future;
 }
 ~~~
@@ -197,15 +195,15 @@ futures are currently not implemented in our futures however such as
 [`shared_future`](http://en.cppreference.com/w/cpp/thread/shared_future),
 [`when_any()`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.when_any).
 
-\subsection simgrid_uhood_timer Timers
+@subsection simgrid_uhood_timer Timers
 
-\section simgrid_uhood_mc Model Checker
+@section simgrid_uhood_mc Model Checker
 
 The current implementation of the model-checker uses two distinct processes:
 
  - the SimGrid model-checker (`simgrid-mc`) itself lives in the parent process;
 
- - it spaws a child process for the SimGrid simulator/maestro and the simulated
+ - it spawns a child process for the SimGrid simulator/maestro and the simulated
    processes.
 
 They communicate using a `AF_UNIX` `SOCK_SEQPACKET` socket and exchange messages
@@ -220,13 +218,13 @@ process using the following techniques:
 - the model-cheker `ptrace()`s the model-checked process and is thus able to
   know the state of the model-checked process if it crashes;
 
-- DWARF debug informations are used to unwind the stack and identify local
+- DWARF debug information are used to unwind the stack and identify local
   variables;
 
 - a custom heap is enabled in the model-checked process which allows the model
   checker to know which chunks are allocated and which are freed.
 
-\subsection simgrid_uhood_mc_address_space Address space
+@subsection simgrid_uhood_mc_address_space Address space
 
 The `AddressSpace` is a base class used for both the model-checked process
 and its snapshots and has methods to read in the corresponding address space:
@@ -243,15 +241,15 @@ Additional helper class include:
  - `RemotePtr<T>` represents the address of an object of type `T` in some
     remote `AddressSpace` (it could be an alias to `Remote<T*>`).
 
-\subsection simgrid_uhood_mc_address_elf_dwarf ELF and DWARF
+@subsection simgrid_uhood_mc_address_elf_dwarf ELF and DWARF
 
 [ELF](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file
 and dynamic libraries file format.
-[DWARF](http://dwarfstd.org/) is a standard for debug informations.
+[DWARF](http://dwarfstd.org/) is a standard for debug information.
 Both are used on GNU/Linux systems and exploited by the model-checker to
 understand the model-checked process:
 
- - `ObjectInformation` represents the informations about a given ELF module
+ - `ObjectInformation` represents the information about a given ELF module
    (executable or shared-object);
 
  - `Frame` represents a subprogram scope (either a subprogram or a scope within