doc/module-gras.doc

   1 /** \addtogroup GRAS_API
   2
   3     \section GRAS_funct Offered functionnalities
   4      - <b>Communication facilities</b>: Exchanging messages between peers
   5        - \ref GRAS_dd: any data which may transit on the network must be
   6          described beforehand so that GRAS can handle the platform
   7          heterogeneity and convert them if needed.
   8        - \ref GRAS_sock: this is how to open a communication channel to
   9          other processes, and retrive information about them.
  10        - \ref GRAS_msg: communications are message oriented. You have to
  11          describe all possible messages and their payload beforehand, and
  12          can then attach callbacks to the arrival of a given kind of message.
  13        - \ref GRAS_timer: this is how to program repetitive and delayed
  14          tasks, not unlike cron(8) and at(1). This cannot be used to timeout
  15          a function (like setitimer(2) or signal(2) games could do).
  16      - <b>Virtualization</b>: Running both on top of the simulator and on
  17        top of real platforms, and portability support.
  18        - \ref GRAS_globals: The use of globals is forbidden since the
  19          "processes" are threads in simulation mode. \n
  20          This is how to let GRAS handle your globals properly.
  21        - \ref GRAS_main_generation: Since processes are threads in
  22           simulation mode and regular processes in the real world, GRAS does
  23           generate your main functions for you.
  24        - \ref GRAS_cond: How to declare specific code for the simulation mode
  25           or for the real mode.
  26        - \ref GRAS_virtu: You naturally don't want to call the
  27           gettimeofday(2) function in simulation mode since it would give
  28           you the time on the host running the simulation, not the time in
  29           the simulated world (you are belonging to).\n
  30           This a system call virtualization layer, which also acts as a
  31           portability layer.
  32
  33     \section GRAS_example Examples
  34
  35     There is for now rather few examples of GRAS, but it's better than
  36     nothing, isn't it?
  37
  38        - \ref GRAS_ex_ping
  39        - \ref GRAS_ex_timer
  40
  41     @{ */
  42        /** \defgroup GRAS_dd      Data description      */
  43        /** \defgroup GRAS_sock    Sockets               */
  44        /** \defgroup GRAS_msg     Messages              */
  45        /** \defgroup GRAS_timer   Timers                */
  46
  47        /** \defgroup GRAS_globals Globals               */
  48        /** \defgroup GRAS_cond    Conditional execution */
  49        /** \defgroup GRAS_virtu   Syscalls              */
  50
  51 /** @} */
  52
  53 /** \page GRAS_main_generation main() and GRAS
  54
  55     <center>[\ref GRAS_API]</center>
  56
  57     \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
  58
  59     In simulation mode, all processes are run as thread of the same process
  60     while they are real processes in the real life. Unfortunately, the main
  61     function of a real process must be called <tt>main</tt> while this
  62     function must not use this name for threads.
  63
  64     To deal with this, you should call the main function of your processes
  65     with another name (usually, the process function such as client, server,
  66     or such). Then GRAS can generate the wrapper functions adapted to the
  67     real and simulated modes.
  68
  69     \section GRAS_maingen_script Generating the main()s manually with
  70
  71     This is done by the gras_stub_generator program, which gets installed on
  72     <tt>make install</tt> (the source resides in the tools/gras/ directory).
  73     Here is the calling syntax:
  74     \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
  75
  76     It parses the deployment file, searching for all the kind of processes
  77     you have in your project. It then generates the following C files:
  78      - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
  79        have\n
  80        They are used to launch your project in real life. They
  81        contain a main() in charge of initializing the GRAS infrastructure and
  82        launching your code afterward.
  83      - a <tt>_<project_name>_simulator.c</tt> file.\n
  84        This file is suited to the simulation mode. It contains a main()
  85        function initializing the simulator and launching your project within.
  86
  87     For this to work, the name of process described in your deployment file
  88     should match the name of a function in your code, which prototype is for
  89     example: \verbatim int client(int argc,char *argv[]);\endverbatim
  90
  91     Unfortunately, all this is still partially documented. I guess I ought
  92     to improve this situation somehow. In the meanwhile, check the generated
  93     code and maybe also the GRAS \ref GRAS_example, sorry.
  94
  95     \section GRAS_maingen_make Integration within your Makefile
  96
  97     The easiest to set it up is to add the following chunk at the end of
  98     your Makefile (or Makefile.am), putting the right values into NAME and
  99     PROCESSES.
 100 \verbatim NAME=your_project_name
 101  PROCESSES=list of processes type in your project
 102
 103  $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
 104         path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
 105 \endverbatim
 106
 107     Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
 108 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
 109         $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
 110 \endverbatim
 111
 112      */
 113
 114 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
 115
 116     <center>[\ref GRAS_API]</center>
 117
 118     This example implements the very classical ping-pong in GRAS. It
 119     involves a client (initiating the ping-pong) and a server (answering to
 120     client's requests).
 121
 122     It works the following way:
 123      - Both the client and the server register all needed messages
 124      - The server registers a callback to the ping message, which sends pong
 125        to the expeditor
 126      - The client sends the ping message to the server, and waits for the
 127        pong message as an answer.
 128
 129     This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
 130     the code of the client and of the server is placed in the same file. See
 131     the \ref GRAS_main_generation section if wondering.
 132
 133     \section GRAS_ex_ping_over Overview
 134       - \ref GRAS_ex_ping_common
 135         - \ref GRAS_ex_ping_initial
 136         - \ref GRAS_ex_ping_register
 137       - \ref GRAS_ex_ping_server
 138         - \ref GRAS_ex_ping_serdata
 139         - \ref GRAS_ex_ping_sercb
 140         - \ref GRAS_ex_ping_sermain
 141       - \ref GRAS_ex_ping_client
 142         - \ref GRAS_ex_ping_climain
 143
 144     <hr>
 145
 146     \dontinclude gras/ping/ping.c
 147
 148     \section GRAS_ex_ping_common 1) Common code to the client and the server
 149
 150     \subsection GRAS_ex_ping_initial 1.a) Initial settings
 151
 152     Let's first load the gras header and declare a logging category (see
 153     \ref XBT_log for more info on logging).
 154
 155     \skip include
 156     \until XBT_LOG
 157
 158     \subsection GRAS_ex_ping_register 1.b) Register the messages
 159
 160     This function, called by both the client and the server is in charge of
 161     declaring the existing messages to GRAS. Since the payload does not
 162     involve any newly created types but only int, this is quite easy.
 163     (to exchange more complicated types, see \ref GRAS_dd)
 164
 165     \skip register_messages
 166     \until }
 167
 168     \section GRAS_ex_ping_server 2) Server's code
 169
 170     \subsection GRAS_ex_ping_serdata 2.a) The server's globals
 171
 172     In order to ensure the communication between the "main" and the callback
 173     of the server, we need to declare some globals. We have to put them in a
 174     struct definition so that they can be handled properly in GRAS (see the
 175     \ref GRAS_globals for more info).
 176
 177     \skip typedef struct
 178     \until }
 179
 180     \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
 181
 182     Here is the callback run when the server receives any ping message (this
 183     will be registered later by the server).
 184
 185     \skip server_cb_ping_handler
 186     \until end_of_server_cb_ping_handler
 187
 188     \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
 189
 190     This is the "main" of the server. As explained in the \ref
 191     GRAS_main_generation, you don't have to (and shouldn't) write any main()
 192     function yourself. Instead, you just have to write a regular function
 193     like this one which will act as a main.
 194
 195     \skip server
 196     \until end_of_server
 197
 198     \section GRAS_ex_ping_client 3) Client's code
 199
 200     \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
 201
 202     \skip client
 203     \until end_of_client
 204   */
 205
 206 /** \page GRAS_ex_timer Some timer games
 207
 208     <center>[\ref GRAS_API]</center>
 209
 210     This example fools around with the GRAS timers (\ref GRAS_timer). It is
 211     mainly a regression test, since it uses almost all timer features.
 212
 213     The main program registers a repetititive task and a delayed one, and
 214     then loops until the <tt>still_to_do</tt> variables of its globals reach
 215     0. The delayed task set it to 5, and the repetititive one decrease it
 216     each time. Here is an example of output:
 217 \verbatim Initialize GRAS
 218  Initialize XBT
 219  [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
 220  [1108335471] Programming the delayed_action for after 2.000000 sec
 221  [1108335471] Have a rest
 222  [1108335472] Canceling the delayed_action.
 223  [1108335472] Re-programming the delayed_action for after 2.000000 sec
 224  [1108335472] Repetitive_action has nothing to do yet
 225  [1108335473] Repetitive_action has nothing to do yet
 226  [1108335473] delayed_action setting globals->still_to_do to 5
 227  [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
 228  [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
 229  [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
 230  [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
 231  [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
 232  Exiting GRAS\endverbatim
 233
 234     Source code:
 235      - \ref GRAS_ex_timer_decl
 236      - \ref GRAS_ex_timer_delay
 237      - \ref GRAS_ex_timer_repeat
 238      - \ref GRAS_ex_timer_main
 239
 240     \dontinclude timer.c
 241
 242     \section GRAS_ex_timer_decl   1. Declarations and headers
 243     \skip include
 244     \until my_globals
 245
 246     \section GRAS_ex_timer_delay  2. Source code of the delayed action
 247     \skip repetitive_action
 248     \until end_of_repetitive_action
 249
 250     \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
 251     \skip delayed_action
 252     \until end_of_delayed_action
 253
 254     \section GRAS_ex_timer_main   4. Source code of main function
 255     \skip client
 256     \until end_of_client
 257 */