X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/c5ad8ca1a68bbaa9152471c8d0eeb99d762f0d86..8802406ce606cc44533b47d4c6f9d3f58a4bdfde:/src/simix/README_attempt_without_stack

diff --git a/src/simix/README_attempt_without_stack b/src/simix/README_attempt_without_stack
index 7563cb9a9d..a7b145fad7 100644
--- a/src/simix/README_attempt_without_stack
+++ b/src/simix/README_attempt_without_stack
@@ -12,7 +12,7 @@ Shiny side: glance at interface
 
 It uses a new simix context factory: state_machine. Each user process
 is a state machine. There is no system mystery such as pthread or
-ucontextes to save its stack. As a result, there is no stack. Each
+ucontexts to save its stack. As a result, there is no stack. Each
 user process only have a user-provided structure describing its state,
 and only compute its next state based on that. Your main() can be as
 simple as:
@@ -35,7 +35,7 @@ simple as:
              the structure describing a process.
 
 This way of organizing the code saves a *huge amount* of memory
-(regular contextes have 128kb stacks per user process, threads are
+(regular contexts have 128kb stacks per user process, threads are
 even more expensive) and greatly speeds things up (there is absolutely
 no nothing to ask to the system, and everything can be done in user
 space).
@@ -59,7 +59,7 @@ Dark side: restrictions on user code
 
 The incredible performance of this approach comes at a price: using
 SimGrid this way is a *real* pain in the ass. You cannot use MSG nor
-GRAS nor SMPI nor nothing (because none of these interfaces were coded
+SMPI nor nothing (because none of these interfaces were coded
 with the *extrem* requirement of the state_machine in mind), and you
 can only rely on SIMIX. From SIMIX, you can only use simcalls (ie, the
 simcall_* functions). Moreover, you must know that each blocking