Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
af308c52994b5c0418493f180b72fb42a82cee66
[simgrid.git] / 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      - <b>Virtualization</b>: Running both on top of the simulator and on
14        top of real platforms, and portability support.
15        - \ref GRAS_globals: The use of globals is forbidden since the
16          "processes" are threads in simulation mode. \n
17          This is how to let GRAS handle your globals properly.
18        - \ref GRAS_main_generation: Since processes are threads in
19           simulation mode and regular processes in the real world, GRAS does
20           generate your main functions for you.
21        - \ref GRAS_cond: How to declare specific code for the simulation mode
22           or for the real mode.
23        - \ref GRAS_virtu: You naturally don't want to call the
24           gettimeofday(2) function in simulation mode since it would give
25           you the time on the host running the simulation, not the time in
26           the simulated world (you are belonging to).\n
27           This a system call virtualization layer, which also acts as a
28           portability layer.
29           
30     \section GRAS_example Examples
31       
32     There is for now rather few examples of GRAS, but it's better than
33     nothing, isn't it?
34     
35        - \ref GRAS_ex_ping 
36                
37     @{ */     
38        /** \defgroup GRAS_dd      Data description      */       
39        /** \defgroup GRAS_sock    Sockets               */           
40        /** \defgroup GRAS_msg     Messages              */               
41          
42        /** \defgroup GRAS_globals Globals               */ 
43        /** \defgroup GRAS_cond    Conditional execution */ 
44        /** \defgroup GRAS_virtu   Syscalls              */ 
45
46 /** @} */
47
48 /** \page GRAS_main_generation main() and GRAS
49
50     <center>[\ref GRAS_API]</center>
51
52     \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
53
54     In simulation mode, all processes are run as thread of the same process
55     while they are real processes in the real life. Unfortunately, the main
56     function of a real process must be called <tt>main</tt> while this
57     function must not use this name for threads.
58     
59     To deal with this, you should call the main function of your processes
60     with another name (usually, the process function such as client, server,
61     or such). Then GRAS can generate the wrapper functions adapted to the
62     real and simulated modes.
63
64     \section GRAS_maingen_script Generating the main()s manually with
65     
66     This is done by the gras_stub_generator script, which lives for now in
67     the examples/gras/ directory. Here is the calling syntax:
68     \verbatim gras_stub_generator <project_name> <deployment_file>\endverbatim
69     
70     It parses the deployment file, searching for all the kind of processes
71     you have in your project. It then generates the following C files:
72      - a file _<project_name>_<process_kind>.c for each process kind you
73        have\n
74        They are used to launch your project in real life. They
75        contain a main() in charge of initializing the GRAS infrastructure and
76        launching your code afterward.
77      - a file _<project_name>_simulator.c.\n
78        This file is suited to the simulation mode. It contains a main()
79        function initializing the simulator and launching your project within.
80     
81     For this to work, the name of process described in your deployment file
82     should match the name of a function in your code, which prototype is for
83     example: \verbatim int client(int argc,char *argv[]);\endverbatim
84     
85     Unfortunately, all this is still partially documented. I guess I ought
86     to improve this situation somehow. In the meanwhile, check the script
87     source code, and the generated code, sorry.
88     
89     \warning All this is about the old description file from SimGrid2 and
90     should be updated to the new SimGrid3 format. We have to change both the
91     code and this documentation.
92     
93     \section GRAS_maingen_make Integration within your Makefile 
94     
95     The easiest to set it up is to add the following chunk at the end of
96     your Makefile (or Makefile.am), putting the right values into NAME and
97     PROCESSES.
98 \verbatim NAME=your_project_name
99  PROCESSES=list of processes type in your project
100
101  $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.txt
102         path/to/gras_stub_generator $(NAME) $(NAME)_deployment.txt >/dev/null
103 \endverbatim
104
105     Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
106 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.txt 
107         $(srcdir)/../gras_stub_generator ping ping_deployment.txt >/dev/null
108 \endverbatim    
109
110      */
111
112 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
113
114     <center>[\ref GRAS_API]</center>
115
116     This example implements the very classical ping-pong in GRAS. It
117     involves a client (initiating the ping-pong) and a server (answering to 
118     client's requests).
119
120     It works the following way:
121      - Both the client and the server register all needed messages
122      - The server registers a callback to the ping message, which sends pong
123        to the expeditor
124      - The client sends the ping message to the server, and waits for the
125        pong message as an answer.
126  
127     This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
128     the code of the client and of the server is placed in the same file. See
129     the \ref GRAS_main_generation section if wondering.
130
131     \section GRAS_ex_ping_over Overview
132       - \ref GRAS_ex_ping_common
133         - \ref GRAS_ex_ping_initial
134         - \ref GRAS_ex_ping_register
135       - \ref GRAS_ex_ping_server
136         - \ref GRAS_ex_ping_serdata
137         - \ref GRAS_ex_ping_sercb
138         - \ref GRAS_ex_ping_sermain
139       - \ref GRAS_ex_ping_client
140         - \ref GRAS_ex_ping_climain
141         
142     <hr>
143
144     \dontinclude gras/ping/ping.c
145     
146     \section GRAS_ex_ping_common 1) Common code to the client and the server 
147     
148     \subsection GRAS_ex_ping_initial 1.a) Initial settings
149     
150     Let's first load the gras header and declare a logging category (see
151     \ref XBT_log for more info on logging).
152     
153     \skip include
154     \until XBT_LOG
155
156     \subsection GRAS_ex_ping_register 1.b) Register the messages
157     
158     This function, called by both the client and the server is in charge of
159     declaring the existing messages to GRAS. Since the payload does not
160     involve any newly created types but only int, this is quite easy. 
161     (to exchange more complicated types, see \ref GRAS_dd)
162     
163     \skip register_messages
164     \until }
165
166     \section GRAS_ex_ping_server 2) Server's code
167     
168     \subsection GRAS_ex_ping_serdata 2.a) The server's globals
169
170     In order to ensure the communication between the "main" and the callback
171     of the server, we need to declare some globals. We have to put them in a
172     struct definition so that they can be handled properly in GRAS (see the
173     \ref GRAS_globals for more info).
174
175     \skip typedef struct
176     \until }
177     
178     \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
179
180     Here is the callback run when the server receives any ping message (this
181     will be registered later by the server).
182     
183     \skip server_cb_ping_handler
184     \until end_of_server_cb_ping_handler
185
186     \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
187     
188     This is the "main" of the server. As explained in the \ref
189     GRAS_main_generation, you don't have to (and shouldn't) write any main()
190     function yourself. Instead, you just have to write a regular function
191     like this one which will act as a main.
192     
193     \skip server
194     \until end_of_server
195     
196     \section GRAS_ex_ping_client 3) Client's code
197     
198     \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
199     
200     \skip client
201     \until end_of_client
202     
203
204   */
205