nobody will ever want to survive such error.
* Create specific errors for each MSG case of failure:
host failure, transfer failure, timeout, task cancelled
+ * Cleanup the exceptions that may get thrown by each function
+ * Other internal cleanups in Java bindings. Performance still bad :/
Ruby and Lua Bindings: create them
* That's new and great, you should try them out.
Same functionalities than Java bindings, only even less polished
* SD_SCHED_NO_COST: Constant to use as cost in SD_task_schedule()
either as comm costs or compute costs to mean that there is no
such thing for that specific task.
+ * Fix SD_task_unschedule() on typed tasks
MSG:
* In trace replay, allow to have one trace file per process.
Give the specific trace file as argument of each process,
* Kill the MSG_paje_output() function. It's a noop since 2 years.
* Kill MSG_WARNING and MSG_FATAL return codes: they were not used
anywere in source.
+ * Rename MSG_TIMEOUT_FAILURE into MSG_TIMEOUT for sake of logic
* Add a MSG_task_set_data() function
+ * About trace replay (see examples/msg/actions):
+ - implement barrier
+ - Allow to work with splitted trace files for each process
SIMIX:
- * add a SIMIX_sem_get_capacity() function
+ * add SIMIX_action_suspend() and SIMIX_action_resume() functions
+ * About semaphores:
+ - Add a SIMIX_sem_get_capacity() function
+ - Fix interactions with processe resume/suspende
+ - release_forever was stupidly broken
+ - Make SIMIX_sem_block_onto() user-visible
+ * Refactoring context stuff:
+ - Use pseudo-OOP for better modularity
+ - reimplement SIMIX_process_kill() without process_schedule() so
+ that the latter can take as invariant that it is called from
+ maestro.
+ - Merge context_start into context_new for sake of simplicity
SURF:
* Rename configuration variables to start a hierarchy:
o cpu_model -> cpu/model
In contrary to regular dicts, the key is not malloced before copy.
Mixing scalar and regular elements in the same dict is not tested
(but may work).
-
+ * Allow to use xbt_dynar_shrink() to expend the dynar instead
+ Tracing for Visualization:
+ * SimGrid is now instrumented in order to generate a trace file for
+ visualization analysis: to use it, need to compile SimGrid with the
+ "tracing" option enabled, and instrument the program using SimGrid with
+ TRACE_start, TRACE_category, TRACE_msg_set_task_category and TRACE_end
+ (among other functions).
+ * The instrumentation only traces the platform utilization for now
+ * Documentation to use the tracing functions and how to analyze the
+ traces with the Triva tool is written.
+ * More information about: SimGrid FAQ (in the section Tracing Simulations
+ for Visualization)
+
-- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr>
