From 035c13f70e88dc4b3a24599a726ba270ab748000 Mon Sep 17 00:00:00 2001 From: mquinson Date: Tue, 28 Apr 2009 10:10:28 +0000 Subject: [PATCH] little improvement to the documentation git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@6263 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- doc/gtut-tour-05-globals.doc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/doc/gtut-tour-05-globals.doc b/doc/gtut-tour-05-globals.doc index b35c3f7c63..11ddb12138 100644 --- a/doc/gtut-tour-05-globals.doc +++ b/doc/gtut-tour-05-globals.doc @@ -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: -- 2.20.1