-/** @addtogroup MSG_API
+/** \defgroup MSG_JAVA jMSG
+ \ingroup MSG_API
+ \brief Java bindings to MSG (\ref MSG_API)
+
+ \htmlonly <!--
+ DOXYGEN_NAVBAR_LABEL="JAVA bindings"
+ DOXYGEN_NAVBAR_CHILD "Simulation functions"=classsimgrid_1_1msg_1_1Msg.html
+ DOXYGEN_NAVBAR_CHILD "Host"=classsimgrid_1_1msg_1_1Host.html
+ DOXYGEN_NAVBAR_CHILD "Process"=classsimgrid_1_1msg_1_1Process.html
+ DOXYGEN_NAVBAR_CHILD "Task"=classsimgrid_1_1msg_1_1Task.html
+ DOXYGEN_NAVBAR_CHILD "MsgException"=classsimgrid_1_1msg_1_1MsgException.html
+ --> \endhtmlonly
+
+ MSG was the first distributed programming environment provided within
+ SimGrid. While almost realistic, it remains quite simple (simplistic?).
+ This describes the Java bindings to this interface.
+
+ \section jMSG_who Who should use this (and who shouldn't)
+
+ You should use MSG if you want to study some heuristics for a
+ given problem you don't really want to implement. If you want to
+ use the Java programming language, your are in the right
+ section. To use the C interface, please refer to \ref MSG_C.
+*/
+
+/** \defgroup MSG_C MSG native
+ \ingroup MSG_API
+ \brief Native interface to MSG (\ref MSG_API)
+
+ \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Native interface" --> \endhtmlonly
+
+ MSG was the first distributed programming environment provided within
+ SimGrid. While almost realistic, it remains quite simple (simplistic?).
+ This describes the native to MSG.
+
+ \section jMSG_who Who should use this (and who shouldn't)
+
+ You should use MSG if you want to study some heuristics for a
+ given problem you don't really want to implement. If you want to
+ use the C programming language, your are in the right
+ section. To use the Java programming interface, please refer to
+ \ref MSG_JAVA.
+*/
+
+
+/**
+
+\defgroup MSG_LUA lMSG
+ \ingroup MSG_API
+ \brief Lua bindings to MSG (\ref MSG_API)
+
+ \htmlonly <!--
+ DOXYGEN_NAVBAR_LABEL="LUA bindings"
+ --> \endhtmlonly
+
+ MSG was the first distributed programming environment provided within
+ SimGrid. While almost realistic, it remains quite simple (simplistic?).
+ This describes the Lua bindings to this interface.
+
+ \section lMSG_who Who should use this (and who shouldn't)
+
+ You should use MSG if you want to study some heuristics for a
+ given problem you don't really want to implement. If you want to
+ use the Lua script language, your are in the right
+ section. To use the C interface, please refer to \ref MSG_C.
+
+*/
+
+/** @addtogroup MSG_C
\section MSG_funct Offered functionnalities
- \ref m_process_management
- \ref MSG_ex_master_slave
*/
+/** @addtogroup MSG_LUA
+
+ \section MSG_Lua_funct Lua offered functionnalities in MSG
+ - \ref host_management
+ - \ref tasks_management
+ - \ref environment_management
+ \section Lua_examples Examples of lua MSG
+
+ - \ref MSG_ex_master_slave_lua
+*/
+
+
/** @defgroup m_datatypes_management MSG Data Types
- @ingroup MSG_API
+ @ingroup MSG_C
@brief This section describes the different datatypes provided by MSG.
\htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Data types" --> \endhtmlonly
*/
/** \addtogroup m_process_management
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup m_host_management
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup m_task_management
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup msg_gos_functions
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup m_channel_management
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup msg_easier_life
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \addtogroup msg_simulation
- \ingroup MSG_API */
+ \ingroup MSG_C */
/** \page MSG_ex_master_slave Master/slave application
-
- <center>[\ref MSG_API]</center>
Simulation of a master-slave application using a realistic platform and
an external description of the deployment.
<hr>
- \dontinclude msg/masterslave/masterslave.c
+ \dontinclude msg/masterslave/masterslave_forwarder.c
\section MSG_ext_ms_code Code of the application
\subsection MSG_ext_ms_forwarder Forwarder code
This function has to be assigned to a #m_process_t that has to behave as a forwarder.
- Just like the master fuction (described in \ref MSG_ext_ms_master), it should not be called directly.
+ Just like the master function (described in \ref MSG_ext_ms_master), it should not be called directly.
C style arguments (argc/argv) are interpreted as a list of host
that will accept those tasks.
\include msg/small_platform.xml
*/
+
+/** \page MSG_ex_master_slave_lua Master/slave Lua application
+
+ Simulation of a master-slave application using lua bindings
+ - \ref MSG_ext_ms_code_lua
+ - \ref MSG_ext_ms_master_lua
+ - \ref MSG_ext_ms_slave_lua
+ - \ref MSG_ext_ms_core_lua
+
+ - \ref MSG_ext_ms_helping
+ - \ref MSG_ext_ms_application
+ - \ref MSG_ext_ms_platform
+
+
+ \dontinclude lua/master_slave.lua
+
+ \section MSG_ext_ms_code_lua Code of the application
+
+ \subsection MSG_ext_ms_master_lua Master code
+
+ as described ine the C native master/Slave exmaple , this function has to be assigned to a m_process_t that will behave as the master.
+
+ Lua style arguments (...) in for the master are interpreted as:
+ - the number of tasks to distribute
+ - the computation size of each task
+ - the size of the files associated to each task
+ - a list of host that will accept those tasks.
+
+ Tasks are dumbly sent in a round-robin style.
+
+ \until end_of_master
+
+
+ \subsection MSG_ext_ms_slave_lua Slave code
+
+ This function has to be assigned to a #m_process_t that has to behave as a slave.
+ This function keeps waiting for tasks and executes them as it receives them.
+
+ \until end_of_slave
+ \subsection MSG_ext_ms_core_lua Simulation core
+
+ in this section the core of the simulation which start by including the simgrid lib for bindings
+ : <i>require "simgrid" </i>
+
+ -# Simulation settings : <i>simgrid.platform</i> creates a realistic
+ environment
+ -# Application deployment : create the agents on the right locations with
+ <i>simgrid.application</i>
+ -# The simulation is run with <i>simgrid.run</i>
+
+ Its arguments are:
+ - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
+ - <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
+
+ \until simgrid.clean()
+
+*/
\ No newline at end of file
