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:
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).
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
simcall will result in an interruption of your execution flow.
Let's take an example: If your code contains:
- smx_action_t act = simcall_comm_isend(......);
+ smx_synchro_t act = simcall_comm_isend(......);
simcall_comm_wait(act);
simcall_comm_destroy(act);