X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/09bb62f11f55964b402d295d0d42d5f679f965fc..ec4271409156a4fbf4da5467ffe42ffbce0271bc:/doc/module-gras.doc diff --git a/doc/module-gras.doc b/doc/module-gras.doc index bca306402e..adeb57f1f1 100644 --- a/doc/module-gras.doc +++ b/doc/module-gras.doc @@ -6,30 +6,31 @@ \section GRAS_funct Offered functionnalities - Communication facilities: Exchanging messages between peers - - \ref GRAS_dd: any data which may transit on the network must be + - \ref GRAS_dd : any data which may transit on the network must be described beforehand so that GRAS can handle the platform heterogeneity and convert them if needed. - - \ref GRAS_sock: this is how to open a communication channel to + - \ref GRAS_sock : this is how to open a communication channel to other processes, and retrive information about them. - - \ref GRAS_msg: communications are message oriented. You have to + - \ref GRAS_msg : communications are message oriented. You have to describe all possible messages and their payload beforehand, and can then attach callbacks to the arrival of a given kind of message. - - \ref GRAS_timer: this is how to program repetitive and delayed + - \ref GRAS_timer : this is how to program repetitive and delayed tasks, not unlike cron(8) and at(1). This cannot be used to timeout a function (like setitimer(2) or signal(2) games could do). - Virtualization: Running both on top of the simulator and on top of real platforms, and portability support. - - \ref GRAS_virtu: You naturally don't want to call the + - \ref GRAS_virtu : You naturally don't want to call the gettimeofday(2) function in simulation mode since it would give you the time on the host running the simulation, not the time in the simulated world (you are belonging to).\n This a system call virtualization layer, which also acts as a portability layer. - - \ref GRAS_globals: The use of globals is forbidden since the + - \ref GRAS_globals : The use of globals is forbidden since the "processes" are threads in simulation mode. \n This is how to let GRAS handle your globals properly. - - \ref GRAS_cond: How to declare specific code for the simulation mode - or for the real mode. + - \ref GRAS_emul : Support to emulate code excution (ie, reporting + execution time into the simulator and having code sections specific + to simulation or to real mode). - Project management tools: Here are some tools which may help you setting up a GRAS project.\n Setting up and building a GRAS application is complicated by the @@ -37,7 +38,7 @@ depending on whether you run on the simulator on a real platform. And then, you'll have to deal with the usual distributed application development difficulties. - - \ref GRAS_main_generation: Since processes are threads in + - \ref GRAS_main_generation : Since processes are threads in simulation mode and regular processes in the real world, GRAS does generate your main functions for you. - \ref GRAS_compile @@ -52,14 +53,14 @@ - \ref GRAS_ex_timer @{ */ - /** \defgroup GRAS_dd Data description */ - /** \defgroup GRAS_sock Sockets */ - /** \defgroup GRAS_msg Messages */ - /** \defgroup GRAS_timer Timers */ + /** @defgroup GRAS_dd Data description */ + /** @defgroup GRAS_sock Sockets */ + /** @defgroup GRAS_msg Messages */ + /** @defgroup GRAS_timer Timers */ - /** \defgroup GRAS_globals Globals */ - /** \defgroup GRAS_cond Conditional execution */ - /** \defgroup GRAS_virtu Syscalls */ + /** @defgroup GRAS_globals Globals */ + /** @defgroup GRAS_emul Emulation support */ + /** @defgroup GRAS_virtu Syscalls */ /** @} */