X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/059ffba3002aa86e17392c7f2c884095ab64591b..4958ce12c0033de2604724d471f5306ed3c3a89f:/doc/gtut-tour-07-timers.doc diff --git a/doc/gtut-tour-07-timers.doc b/doc/gtut-tour-07-timers.doc index d584f261c1..7d45e04f56 100644 --- a/doc/gtut-tour-07-timers.doc +++ b/doc/gtut-tour-07-timers.doc @@ -5,7 +5,7 @@ - \ref GRAS_tut_tour_timers_intro - \ref GRAS_tut_tour_timers_use - \ref GRAS_tut_tour_timers_recap - +
\section GRAS_tut_tour_timers_intro Introduction @@ -25,7 +25,7 @@ coordinator? One solution is to have the members re-register periodically, so that the coordinator can detect the processes which didn't do so since a while, and -dismiss them. +dismiss them. To implement this in GRAS, we need some more functions: gras_timer_repeat() allows to specify a periodic action and gras_timer_delay() allows to get an @@ -52,7 +52,7 @@ first need to add a global to the server too, containing the socket binded onto the server (to send messages) and a boolean indicating whether we are done or not, just like we did on the server side in \ref GRAS_tut_tour_globals. Here is the resulting global structure: -\don'tinclude 07-timers.c +\dontinclude 07-timers.c \skip client_data \until client_data_t @@ -71,7 +71,7 @@ Desinstalling this is not harder. You tell the action to unschedule, and the periodicity at which it was desinstalled (so that the same action can be scheduled at different intervals, and each of them be desinstallable separately). -\don'tinclude 07-timers.c +\dontinclude 07-timers.c \skip gras_timer_cancel_repeat \until gras_timer_cancel_repeat @@ -79,7 +79,7 @@ Then comes the delayed action in charge of stopping everything, which should be self-explanatory at this point. It could be cancelled before its expiration using gras_timer_cancel_delay(), which accepts exactly the same kind of arguments than gras_timer_cancel_repeat(). -\don'tinclude 07-timers.c +\dontinclude 07-timers.c \skip client_do_stop \until end_of_client_do_stop