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
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
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
\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.
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:
