Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
886da4737c63ae6f184eb121252b89fe6a6b0850
[simgrid.git] / doc / module-gras.doc
1 #####################################################################
2 ###########################  CORE ###################################
3 #####################################################################
4
5 /** \addtogroup GRAS_API
6   
7     \section GRAS_funct Offered functionnalities
8      - <b>\ref GRAS_comm</b>: Exchanging messages between peers
9        - \ref GRAS_dd : any data which may transit on the network must be
10          described beforehand so that GRAS can handle the platform
11          heterogeneity and convert them if needed.
12        - \ref GRAS_sock : this is how to open a communication channel to
13          other processes, and retrive information about them.
14        - \ref GRAS_msg : communications are message oriented. You have to
15          describe all possible messages and their payload beforehand, and
16          can then attach callbacks to the arrival of a given kind of message. 
17        - \ref GRAS_timer : this is how to program repetitive and delayed
18          tasks, not unlike cron(8) and at(1). This cannot be used to timeout
19          a function (like setitimer(2) or signal(2) games could do).
20      - <b>\ref GRAS_run</b>: Running both on top of the simulator and on
21        top of real platforms, and portability support.
22        - \ref GRAS_virtu : You naturally don't want to call the
23           gettimeofday(2) function in simulation mode since it would give
24           you the time on the host running the simulation, not the time in
25           the simulated world (you are belonging to).\n
26           This a system call virtualization layer, which also acts as a
27           portability layer.
28        - \ref GRAS_globals : The use of globals is forbidden since the
29          "processes" are threads in simulation mode. \n
30          This is how to let GRAS handle your globals properly.
31        - \ref GRAS_emul : Support to emulate code excution (ie, reporting
32          execution time into the simulator and having code sections specific
33          to simulation or to real mode).
34      - <b>\ref GRAS_code</b>: Here are some tools which may help
35           you setting up a GRAS project.\n
36           Setting up and building a GRAS application is complicated by the
37           library schizoid. The code to setup the environment differs
38           depending on whether you run on the simulator on a real platform.
39           And then, you'll have to deal with the usual distributed
40           application development difficulties.
41        - \ref GRAS_main_generation : Since processes are threads in
42           simulation mode and regular processes in the real world, GRAS does
43           generate your main functions for you.
44        - \ref GRAS_compile
45      
46           
47     \section GRAS_example Examples
48       
49     There is for now rather few examples of GRAS, but it's better than
50     nothing, isn't it?
51     
52        - \ref GRAS_ex_ping
53        - \ref GRAS_ex_mmrpc
54        - \ref GRAS_ex_token
55        - \ref GRAS_ex_timer
56
57     @{ */
58        /** @defgroup GRAS_comm    Communication facilities */
59        /** @defgroup GRAS_run     Virtualization */
60        /** @defgroup GRAS_code    Project and code management */
61        /** @defgroup GRAS_ex      Examples */
62 /** @} */
63 #####################################################################
64 /** @addtogroup GRAS_comm
65
66    Here are the communication facilities. GRAS allows you to exchange
67    <i>messages</i> on <i>sockets</i> (which can be seen as pipes between
68    processes). On reception, messages start <i>callbacks</i> (that's the
69    default communication mode, not the only one). All messages of a given
70    type convey the same kind of data, and you have to describe it
71    beforehand.
72
73    Timers are also seen as a mean of communication (with yourself). It
74    allows you to run a repetitive task ("do this every N second until I tell
75    you to stop"), or to deffer a treatment ("do this in 3 sec").
76
77     @{ */     
78        /** @defgroup GRAS_dd      Data description      */       
79        /** @defgroup GRAS_sock    Sockets               */           
80        /** @defgroup GRAS_msg     Messages              */               
81        /** @defgroup GRAS_timer   Timers                */               
82      
83 /** @} */
84 #####################################################################
85 /** @addtogroup GRAS_run
86
87    Virtualization facilities allow your code to run both on top of the simulator or in real setting.
88
89     @{ */     
90          
91        /** @defgroup GRAS_globals Globals               */ 
92        /** @defgroup GRAS_emul    Emulation support */ 
93        /** @defgroup GRAS_virtu   Syscalls              */ 
94
95 /** @} */
96
97 #####################################################################
98 /** @addtogroup GRAS_code
99
100     Here is how to setup your code when you want to use GRAS. You will also
101     learn how to get the most repetitive parts of your code generated
102     automatically.
103
104     (use the tabs on top of the page to navigate)
105
106     \htmlonly <!-- 
107       DOXYGEN_NAVBAR_LABEL="Project management"
108       DOXYGEN_NAVBAR_CHILD "main() and GRAS"=GRAS_main_generation.html
109       DOXYGEN_NAVBAR_CHILD "Compiling your GRAS project"=GRAS_compile.html
110     --> \endhtmlonly
111 */
112
113 #####################################################################
114 /** @addtogroup GRAS_ex
115
116     There is for now rather few examples of GRAS, but it's better than
117     nothing, isn't it?
118
119        - \ref GRAS_ex_ping
120        - \ref GRAS_ex_mmrpc
121        - \ref GRAS_ex_token
122        - \ref GRAS_ex_timer
123
124     \htmlonly <!-- 
125       DOXYGEN_NAVBAR_CHILD "Ping-Pong"=GRAS_ex_ping.html
126       DOXYGEN_NAVBAR_CHILD "RPC"=GRAS_ex_mmrpc.html
127       DOXYGEN_NAVBAR_CHILD "Token Ring"=GRAS_ex_token.html
128       DOXYGEN_NAVBAR_CHILD "Timers"=GRAS_ex_timer.html
129     --> \endhtmlonly
130
131   There is some more examples in the distribution, under the directory
132   <tt>examples/gras</tt>.
133 */
134
135 #####################################################################
136 #########################  EXTRA PAGES ##############################
137 #####################################################################
138
139 ---------------------------------------------------------------------
140 --------------------- main() generation -----------------------------
141 ---------------------------------------------------------------------
142
143 /** \page GRAS_main_generation main function
144
145     \section GRAS_maingen_toc Table of content
146      
147      - \ref GRAS_maingen_intro
148      - \ref GRAS_maingen_script
149      - \ref GRAS_maingen_make
150     
151     <hr>
152
153     \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
154
155     In simulation mode, all processes are run as thread of the same process
156     while they are real processes in the real life. Unfortunately, the main
157     function of a real process must be called <tt>main</tt> while this
158     function must not use this name for threads.
159     
160     To deal with this, you should call the main function of your processes
161     with another name (usually, the process function such as client, server,
162     or such). Then GRAS can generate the wrapper functions adapted to the
163     real and simulated modes.
164
165     \section GRAS_maingen_script Generating the main()s automatically
166     
167     This is done by the gras_stub_generator program, which gets installed on
168     <tt>make install</tt> (the source resides in the tools/gras/ directory).
169     Here is the calling syntax: 
170     \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
171     
172     It parses the deployment file, searching for all the kind of processes
173     you have in your project. It then generates the following C files:
174      - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
175        have\n
176        They are used to launch your project in real life. They
177        contain a main() in charge of initializing the GRAS infrastructure and
178        launching your code afterward.
179      - a <tt>_<project_name>_simulator.c</tt> file.\n
180        This file is suited to the simulation mode. It contains a main()
181        function initializing the simulator and launching your project within.
182     
183     For this to work, the name of process described in your deployment file
184     should match the name of a function in your code, which prototype is for
185     example: \verbatim int client(int argc,char *argv[]);\endverbatim
186     
187     Unfortunately, all this is still partially documented. I guess I ought
188     to improve this situation somehow. In the meanwhile, check the generated 
189     code and maybe also the GRAS \ref GRAS_example, sorry. 
190         
191     \section GRAS_maingen_make Integration within an hand-made Makefile 
192     
193     The easiest to set it up is to add the following chunk at the end of
194     your Makefile (or Makefile.am), putting the right values into NAME and
195     PROCESSES.
196 \verbatim NAME=your_project_name
197  PROCESSES=list of processes type in your project
198
199  $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
200         path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
201 \endverbatim
202
203     Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
204 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml 
205         $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
206 \endverbatim
207
208    \warning 
209    Actually, gras_stub_generator also generates some makefiles both for
210    local compilation and remote code distribution and installation. See the
211    section \ref GRAS_compile for more details.
212
213 */
214
215 ---------------------------------------------------------------------
216 ------------------------- Compiling ---------------------------------
217 ---------------------------------------------------------------------
218
219 /** \page GRAS_compile Compiling your project
220
221     As explained in section \ref GRAS_main_generation, the
222     gras_stub_generator tool can be used to generate the system
223     initialization code in your projet. While we were at this, this tool
224     also generates the makefiles you will need to compile your project
225     properly.
226     
227     Code source deployment and remote compilation also constitutes a
228     challenging area in distributed applications development. The GRASPE
229     (GRAS Platform Expender) tool was designed to make this less painful.
230
231     \section GRAS_compile_toc Table of content
232     
233       - \ref GRAS_compile_local
234         - \ref GRAS_compile_local_install
235         - \ref GRAS_compile_local_helpfiles
236         - \ref GRAS_compile_local_makefile
237       - \ref GRAS_compile_remote
238       
239     <hr>
240     
241     \section GRAS_compile_local Local compilation of GRAS projects
242     
243     \subsection GRAS_compile_local_install Installing SimGrid and GRAS
244     
245     To compile locally a GRAS project, you first need to install SimGrid on
246     your machine. Use the --prefix flag to the configure script to specify
247     where you want to install the toolkit (refere to section \ref
248     faq_compiling for more information)
249     
250     \subsection GRAS_compile_local_helpfiles Simulation description files
251     
252     Then, you will probably need to write a platform description file and
253     application deployment description file to feed the simulator with. This
254     part is unfortunatelly not documented enough. Files examples can be
255     found along with the MSG \ref MSG_ex_master_slave example. 
256
257     \note yes, both platform and application description files are portable
258     between MSG and GRAS. Actually, there depend on the SURF, not on the
259     programming environment you use.
260     
261     For the first try, you could probably reuse the provided platform file
262     as is while you will need to adapt the application file to fit your
263     needs. 
264     
265     To generate new platform files, we usually use the Tiers Topology
266     Generator (ask google about it) and annotate the generated graph with
267     home-made scripts to let them fit the SURF. Those scripts live in the
268     tools/platform_generation/ directory of the distribution.
269     
270     \subsection GRAS_compile_local_makefile Generating a Makefile usable for your project
271     
272     From the information contained in the application description file, the
273     gras_stub_generator tool can create a Makefile which can be used to
274     seamlessly compile your project. Just go to the directory containing all
275     your project files, and type:
276     
277 \verbatim path/to/gras_stub_generator [project_name] [application_deployment.file] >/dev/null
278 \endverbatim
279
280     The first argument is the name of your project, such as
281     "MyLovelyApplication" while the second one is the application deployment
282     file. 
283     
284     Several files get generated by this command. One C file per kind of
285     process in your project (such as "master" and "slave") plus one C file
286     for simulating your project. All those files are (or should ;) described
287     in section \ref GRAS_main_generation.
288     
289     The most intersting file in this context is
290     [project_name].Makefile.local (you can safely ignore the others for
291     now). To use it, simply type (from your project main directory):
292     
293 \verbatim GRAS_ROOT=/path/to/simgrid/installation make -f [project_name].Makefile.local
294 \endverbatim
295     
296     And that's it, all the binaries are built and linked against the correct
297     libraries.
298     
299     \section GRAS_compile_remote Distribution and remote compilation of GRAS projects
300     
301     Actually, there is two somehow parallel ways to do so since both Arnaud
302     and Martin gave it a try. Merging both approaches is underway. As usual,
303     if you want to help, you're welcome ;)
304     
305 */
306
307 #####################################################################
308 #########################  EXAMPLES #################################
309 #####################################################################
310
311 ---------------------------------------------------------------------
312 ------------------------- Ping Pong ---------------------------------
313 ---------------------------------------------------------------------
314
315 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
316
317     This example implements the very classical ping-pong in GRAS. It
318     involves a client (initiating the ping-pong) and a server (answering to 
319     client's requests).
320
321     It works the following way:
322      - Both the client and the server register all needed messages
323      - The server registers a callback to the ping message, which sends pong
324        to the expeditor
325      - The client sends the ping message to the server, and waits for the
326        pong message as an answer.
327  
328     This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
329     the code of the client and of the server is placed in the same file. See
330     the \ref GRAS_main_generation section if wondering.
331
332     \section GRAS_ex_ping_toc Table of contents of the ping example
333       - \ref GRAS_ex_ping_common
334         - \ref GRAS_ex_ping_initial
335         - \ref GRAS_ex_ping_register
336       - \ref GRAS_ex_ping_server
337         - \ref GRAS_ex_ping_serdata
338         - \ref GRAS_ex_ping_sercb
339         - \ref GRAS_ex_ping_sermain
340       - \ref GRAS_ex_ping_client
341         - \ref GRAS_ex_ping_climain
342         
343     <hr>
344
345     \dontinclude gras/ping/ping_common.c
346     
347     \section GRAS_ex_ping_common 1) Common code to the client and the server 
348     
349     \subsection GRAS_ex_ping_initial 1.a) Initial settings
350     
351     Let's first load the module header and declare a logging category (see
352     \ref XBT_log for more info on logging).
353     
354     \skip include
355     \until XBT_LOG
356     
357     The module header <tt>ping.h</tt> reads:
358     
359     \dontinclude gras/ping/ping.h
360     \skip include
361     \until argv
362     \until argv
363
364     \subsection GRAS_ex_ping_register 1.b) Register the messages
365     
366     This function, called by both the client and the server is in charge of
367     declaring the existing messages to GRAS. Since the payload does not
368     involve any newly created types but only int, this is quite easy. 
369     (to exchange more complicated types, see \ref GRAS_dd or 
370     \ref GRAS_ex_mmrpc for an example).
371
372     \dontinclude gras/ping/ping_common.c
373     \skip register_messages
374     \until }
375
376     [Back to \ref GRAS_ex_ping_toc]
377
378     \section GRAS_ex_ping_server 2) Server's code
379     
380     \subsection GRAS_ex_ping_serdata 2.a) The server's globals
381
382     In order to ensure the communication between the "main" and the callback
383     of the server, we need to declare some globals. We have to put them in a
384     struct definition so that they can be handled properly in GRAS (see the
385     \ref GRAS_globals for more info).
386
387     \dontinclude gras/ping/ping_server.c
388     \skip typedef struct
389     \until }
390     
391     \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
392
393     Here is the callback run when the server receives any ping message (this
394     will be registered later by the server).
395     
396     \skip server_cb_ping_handler
397     \until end_of_server_cb_ping_handler
398
399     \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
400     
401     This is the "main" of the server. As explained in the \ref
402     GRAS_main_generation, you must not write any main()
403     function yourself. Instead, you just have to write a regular function
404     like this one which will act as a main.
405     
406     \skip server
407     \until end_of_server
408
409     [Back to \ref GRAS_ex_ping_toc]
410     
411     \section GRAS_ex_ping_client 3) Client's code
412     
413     \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
414     
415     This function is quite straightforward, and the inlined comments should
416     be enough to understand it.
417
418     \dontinclude gras/ping/ping_client.c
419     \skip client
420     \until end_of_client
421
422     [Back to \ref GRAS_ex_ping_toc]
423  */
424
425 ---------------------------------------------------------------------
426 --------------------- Simple Token Ring -----------------------------
427 ---------------------------------------------------------------------
428
429 /** \page GRAS_ex_token Token Ring example
430
431    This example implements the token ring algorithm. It involves several
432    nodes arranged in a ring (each of them have a left and a right neighbour)
433    and exchanging a "token". This algorithm is one of the solution to ensure
434    the mutual exclusion between distributed processes. There is only one
435    token at any time, so the process in its possession is ensured to be the
436    only one having it. So, if there is an action you want all processes to
437    do alternativly, but you cannot afford to have two processes doing it at
438    the same time, let the process having the token doing it.
439    
440    Actually, there is a lot of different token ring algorithms in the
441    litterature, so this example implements one of them: the simplest one.
442    The ring is static (no new node can join it, and you'll get trouble if
443    one node dies or leaves), and nothing is done for the case in which the
444    token is lost. 
445
446    - \ref GRAS_ex_stoken_deploy
447    - \ref GRAS_ex_stoken_global
448    - \ref GRAS_ex_stoken_callback
449    - \ref GRAS_ex_stoken_main
450
451    \section GRAS_ex_stoken_deploy 1) Deployment file
452
453    Here is the deployment file:
454    \include examples/gras/tokenS/tokenS_deployment.xml
455    
456    The neighbour of each node is given at startup as command line argument.
457    Moreover, one of the nodes is instructed by a specific argument (the one
458    on Tremblay here) to create the token at the begining of the algorithm.
459    
460    \section GRAS_ex_stoken_global 2) Global definition
461    
462    The token is incarned by a specific message, which circulates from node
463    to node (the payload is an integer incremented at each hop). So, the most
464    important part of the code is the message callback, which forwards the
465    message to the next node. That is why we have to store all variable in a
466    global, as explained in the \ref GRAS_globals section. 
467
468    \dontinclude examples/gras/tokenS/tokenS.c
469    \skip typedef
470    \until }
471    
472    \section GRAS_ex_stoken_callback 3) The callback
473    
474    Even if this is the core of this algorithm, this function is quite
475    straightforward.
476    
477    \skip node_cb_stoken_handler
478    \until end_of_node_cb_stoken_handler
479
480    \section GRAS_ex_stoken_main 4) The main function
481    
482    This function is splited in two parts: The first one performs all the
483    needed initialisations (points 1-7) while the end (point 8. below) calls 
484    gras_msg_handle() as long as the planned amount of ring loops are not
485    performed.
486    
487    \skip node
488    \until end_of_node
489
490 */
491
492 ---------------------------------------------------------------------
493 -------------------------- MM RPC -----------------------------------
494 ---------------------------------------------------------------------
495
496 /** \page GRAS_ex_mmrpc A simple RPC for matrix multiplication
497
498     This example implements a remote matrix multiplication. It involves a client 
499     (creating the matrices and sending the multiplications requests) and a server 
500     (computing the multiplication on client's behalf).
501
502     This example also constitutes a more advanced example of data description 
503     mechanisms, since the message payload type is a bit more complicated than in 
504     other examples such as the ping one (\ref GRAS_ex_ping).
505
506     It works the following way (not very different from the ping example):
507      - Both the client and the server register all needed messages and datatypes
508      - The server registers a callback to the "request" message, which computes
509        what needs to be and returns the result to the expeditor.
510      - The client creates two matrices, ask for their multiplication and check 
511        the server's answer.
512  
513     This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
514     the \ref GRAS_main_generation section if wondering why both the server
515     and the client live in the same source file)
516
517     \section GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
518       - \ref GRAS_ex_mmrpc_common
519         - \ref GRAS_ex_mmrpc_header
520         - \ref GRAS_ex_mmrpc_dataregister
521         - \ref GRAS_ex_mmrpc_logdef
522         - \ref GRAS_ex_mmrpc_msgregister
523         - \ref GRAS_ex_mmrpc_matdump
524       - \ref GRAS_ex_mmrpc_server
525         - \ref GRAS_ex_mmrpc_serinc
526         - \ref GRAS_ex_mmrpc_sercb
527         - \ref GRAS_ex_mmrpc_sermain
528       - \ref GRAS_ex_mmrpc_client
529         - \ref GRAS_ex_mmrpc_cliinc
530         - \ref GRAS_ex_mmrpc_climain
531         
532     <hr>
533
534     
535     \section GRAS_ex_mmrpc_common 1) Common code to the client and the server (mmrpc_common.c and mmrpc.h)
536     
537     
538     \subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
539
540     This loads the gras header and declare the function's prototypes as well
541     as the matrix size.
542
543     \dontinclude gras/mmrpc/mmrpc.h
544     \skip include
545     \until argv
546     \until argv
547
548     \subsection GRAS_ex_mmrpc_dataregister 1.b) Register the data types (mmrpc.h)
549
550     The messages involved in this example do use structures as payload, 
551     so we have to declare it to GRAS. Hopefully, this can be done easily by enclosing 
552     the structure declaration within a \ref GRAS_DEFINE_TYPE macro call. It will then copy this 
553     declaration into an hidden string variable, which can be automatically parsed at 
554     run time. Of course, the declaration is also copied unmodified by this macro, so that it
555     gets parsed by the compiler also. 
556
557     There is some semantic that GRAS cannot guess alone and you need to  <i>annotate</i>
558     your declaration to add some. For example, the ctn pointer can be a reference to an 
559     object or a whole array (in which case you also has to specify its size). This is done 
560     with the GRAS_ANNOTE call. It is removed from the text passed to the compiler, but it helps
561     GRAS getting some information about the semantic of your data. Here, it says that \a ctn is an 
562     array, which size is the result of the operation \a rows * \a cols (with \a rows and \a cols 
563     being the other fields of the structure). 
564
565     Please note that this annotation mechanism is not as robust and cool as this example seems to 
566     imply. If you want to use it yourself, you'd better use the exact right syntax, which is 
567     detailed in the \ref GRAS_dd section.
568
569     \skip GRAS_DEFINE_TYPE
570     \until matrix_t
571
572     \subsection GRAS_ex_mmrpc_logdef 1.c) Logging category definition (mmrpc_common.c)
573     
574     Let's first load the module header and declare a logging category (see
575     \ref XBT_log for more info on logging). This logging category does live
576     in this file (ie the required symbols are defined here and declared as
577     "extern" in any other file using them). That is why we use 
578     \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and 
579     \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
580     
581     \dontinclude gras/mmrpc/mmrpc_common.c
582     \skip include
583     \until XBT_LOG
584
585     \subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
586     
587     This function, called by both the client and the server is in charge of
588     declaring the existing messages to GRAS. Note the use of the \ref gras_datadesc_by_symbol 
589     function to parse and retrieve the structure declaration which were passed to \ref GRAS_DEFINE_TYPE 
590     above. 
591
592     The datatype description builded that way can then be used to build an array datatype or 
593     to declare messages.
594     
595     \skip register_messages
596     \until }
597
598     \subsection GRAS_ex_mmrpc_matdump 1.e) Helper debugging function (mmrpc_common.c)
599
600     This function dumps a matrix to screen for debugging.
601     
602     \skip mat_dump
603     \until end_of_matrix
604     \until }
605
606     [Back to \ref GRAS_ex_mmrpc_toc]
607
608     \section GRAS_ex_mmrpc_server 2) Server's code (mmrpc_server.c)
609     
610     \subsection GRAS_ex_mmrpc_serinc 2.a) Server intial settings
611     
612     All module symbols live in the mmrpc_common.c file. We thus have to
613     define \ref GRAS_DEFINE_TYPE_EXTERN to the preprocessor so that the
614     \ref GRAS_DEFINE_TYPE symbols don't get included here. Likewise, we use 
615     \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
616     
617     \dontinclude gras/mmrpc/mmrpc_server.c
618     \skip define
619     \until XBT_LOG
620
621     \subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
622
623     Here is the callback run when the server receives any mmrpc message (this
624     will be registered later by the server). Note the way we get the message 
625     payload. In the ping example, there was one additional level of pointer 
626     indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
627     an array here (ie a pointer) whereas it is a scalar in the ping example.
628     
629     \skip server_cb_request_handler
630     \until end_of_server_cb_request_handler
631
632     \subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
633     
634     This is the "main" of the server. As explained in the \ref
635     GRAS_main_generation, you must not write any main()
636     function yourself. Instead, you just have to write a regular function
637     like this one which will act as a main.
638     
639     \skip server
640     \until end_of_server
641     
642     [Back to \ref GRAS_ex_mmrpc_toc]
643
644     \section GRAS_ex_mmrpc_client 3) Client's code (mmrpc_client.c)
645     
646     \subsection GRAS_ex_mmrpc_cliinc 2.a) Server intial settings
647     
648     As for the server, some extra love is needed to make sure that automatic
649     datatype parsing and log categories do work even if we are using several
650     files.  
651     
652     \dontinclude gras/mmrpc/mmrpc_client.c
653     \skip define
654     \until XBT_LOG
655
656     \subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
657     
658     This function is quite straightforward, and the inlined comments should
659     be enough to understand it.
660
661     \dontinclude gras/mmrpc/mmrpc_client.c
662     \skip argv
663     \until end_of_client
664
665     [Back to \ref GRAS_ex_mmrpc_toc]
666   */
667
668 ---------------------------------------------------------------------
669 ---------------------------- Timers ---------------------------------
670 ---------------------------------------------------------------------
671
672 /** \page GRAS_ex_timer Some timer games
673
674     This example fools around with the GRAS timers (\ref GRAS_timer). It is
675     mainly a regression test, since it uses almost all timer features.
676     
677     The main program registers a repetititive task and a delayed one, and
678     then loops until the <tt>still_to_do</tt> variables of its globals reach
679     0. The delayed task set it to 5, and the repetititive one decrease it
680     each time. Here is an example of output:
681 \verbatim Initialize GRAS
682  Initialize XBT
683  [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
684  [1108335471] Programming the delayed_action for after 2.000000 sec
685  [1108335471] Have a rest
686  [1108335472] Canceling the delayed_action.
687  [1108335472] Re-programming the delayed_action for after 2.000000 sec
688  [1108335472] Repetitive_action has nothing to do yet
689  [1108335473] Repetitive_action has nothing to do yet
690  [1108335473] delayed_action setting globals->still_to_do to 5
691  [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
692  [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
693  [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
694  [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
695  [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
696  Exiting GRAS\endverbatim
697
698     Source code:
699      - \ref GRAS_ex_timer_decl
700      - \ref GRAS_ex_timer_delay
701      - \ref GRAS_ex_timer_repeat
702      - \ref GRAS_ex_timer_main
703
704     \dontinclude timer.c
705     
706     \section GRAS_ex_timer_decl   1. Declarations and headers
707     \skip include
708     \until my_globals
709     
710     \section GRAS_ex_timer_delay  2. Source code of the delayed action
711     \skip repetitive_action
712     \until end_of_repetitive_action
713     
714     \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
715     \skip delayed_action
716     \until end_of_delayed_action
717     
718     \section GRAS_ex_timer_main   4. Source code of main function
719     \skip client
720     \until end_of_client
721 */