X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/c226af4f5e4ed82d142b9065446658bde792072b..c53d0aac5a5ab41701f3320d95f1cd2b0f3fd005:/doc/gtut-tour-05-globals.doc

diff --git a/doc/gtut-tour-05-globals.doc b/doc/gtut-tour-05-globals.doc
index b35c3f7c63..32450ce17f 100644
--- a/doc/gtut-tour-05-globals.doc
+++ b/doc/gtut-tour-05-globals.doc
@@ -28,7 +28,7 @@ it with the gras_userdata_* functions (there is only 3 of them ;).
 We will now modify the example to add a "kill" message, and let the server
 loop on incoming messages until it gets such a message. We only need a
 boolean, so the structure is quite simple: 
-\dontinclude 05-globals.c
+\don'tinclude 05-globals.c
 \skip struct
 \until server_data
  
@@ -38,7 +38,7 @@ helper macro mallocing the space needed by the structure and passing it to
 gras using the latter function. If you go for gras_userdata_set(), you
 should pass it a pointer to your data you want to retrieve afterward.
 
-\dontinclude 05-globals.c
+\don'tinclude 05-globals.c
 \skip userdata_new
 \until userdata_new
 
@@ -49,13 +49,13 @@ defined as being of type server_data_t*.
 
 Once you declared a global that way, retriving this (for example in a
 callback) is really easy:
-\dontinclude 05-globals.c
+\don'tinclude 05-globals.c
 \skip userdata_get
 \until userdata_get
 
 We can now write the callback, which simply retrive the globals and change
 the value of the <tt>kileld</tt> field.
-\dontinclude 05-globals.c
+\don'tinclude 05-globals.c
 \skip kill_cb
 \until end_of_kill_callback
 
@@ -64,6 +64,13 @@ loop:
 \skip while
 \until }
 
+Please note that in our example, only one process creates a global
+structure. But this is naturally completely ok to have several
+processes creating their globals this way. Each of these globals will
+be separated, so process A cannot access globals defined by process B.
+Maybe this implies that the name "globals" is a bit misleading. It
+should be "process state" or something similar.
+
 \section GRAS_tut_tour_callback_pitfall Common pitfall of globals
 
 There is an error that I do myself every other day using globals in GRAS.
@@ -82,6 +89,12 @@ embarass GRAS since it does not have its internal buffer initialized yet,
 and cannot store your data anywhere. That is why doing so triggers an error
 at run time.
 
+Also, as noted above, the gras_userdata_new expects the pointed type,
+not the pointer type. As you can see, in our example, you should pass
+server_data_t to the macro, even if the global variable is later
+defined as being of type server_data_t*.
+
+
 \section GRAS_tut_tour_callback_recap Recaping everything together
 
 The whole program now reads: