other processes, and retrive information about them.
- \ref GRAS_msg : communications are message oriented. You have to
describe all possible messages and their payload beforehand, and
other processes, and retrive information about them.
- \ref GRAS_msg : communications are message oriented. You have to
describe all possible messages and their payload beforehand, and
- \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).
- \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).
This is how to let GRAS handle your globals properly.
- \ref GRAS_emul : Support to emulate code excution (ie, reporting
execution time into the simulator and having code sections specific
This is how to let GRAS handle your globals properly.
- \ref GRAS_emul : Support to emulate code excution (ie, reporting
execution time into the simulator and having code sections specific
We even have a tutorial for the GRAS framework. It details in a
hopefully pedagogic order all the points of the API, along with example
of use for each of them. Unfortunately, it is not finished yet (the main
part missing is the one on how to describe data). Here is the table of
content:
We even have a tutorial for the GRAS framework. It details in a
hopefully pedagogic order all the points of the API, along with example
of use for each of them. Unfortunately, it is not finished yet (the main
part missing is the one on how to describe data). Here is the table of
content:
The tutorial and the API documentation present the framework little
piece by little piece and provide a lot of information on each of them.
Quite orthogonally to this, the HOWTOs try to present transversal
The tutorial and the API documentation present the framework little
piece by little piece and provide a lot of information on each of them.
Quite orthogonally to this, the HOWTOs try to present transversal
allows you to run a repetitive task ("do this every N second until I tell
you to stop"), or to deffer a treatment ("do this in 3 sec").
allows you to run a repetitive task ("do this every N second until I tell
you to stop"), or to deffer a treatment ("do this in 3 sec").
- @{ */
- /** @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 */
+
/** @} */
#####################################################################
/** @addtogroup GRAS_run
Virtualization facilities allow your code to run both on top of the simulator or in real setting.
/** @} */
#####################################################################
/** @addtogroup GRAS_run
Virtualization facilities allow your code to run both on top of the simulator or in real setting.
- @{ */
-
- /** @defgroup GRAS_globals Globals */
- /** @defgroup GRAS_emul Emulation support */
- /** @defgroup GRAS_virtu Syscalls */
+ @{ */
+
+ /** @defgroup GRAS_globals Globals */
+ /** @defgroup GRAS_emul Emulation support */
+ /** @defgroup GRAS_virtu Syscalls */
- \ref GRAS_tut_tour_explicitwait_use
There is some more examples in the distribution, under the directory
- \ref GRAS_tut_tour_explicitwait_use
There is some more examples in the distribution, under the directory
to the expeditor
- The client sends the ping message to the server, and waits for the
pong message as an answer.
to the expeditor
- The client sends the ping message to the server, and waits for the
pong message as an answer.
This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
the code of the client and of the server is placed in the same file. See
the \ref GRAS_tut_tour_setup of the tutorial if wondering.
This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
the code of the client and of the server is placed in the same file. See
the \ref GRAS_tut_tour_setup of the tutorial if wondering.
- \ref GRAS_ex_ping_sermain
- \ref GRAS_ex_ping_client
- \ref GRAS_ex_ping_climain
- \ref GRAS_ex_ping_sermain
- \ref GRAS_ex_ping_client
- \ref GRAS_ex_ping_climain
Let's first load the module header and declare a logging category (see
\ref XBT_log for more info on logging).
Let's first load the module header and declare a logging category (see
\ref XBT_log for more info on logging).
This function, called by both the client and the server is in charge of
declaring the existing messages to GRAS. Since the payload does not
This function, called by both the client and the server is in charge of
declaring the existing messages to GRAS. Since the payload does not
- involve any newly created types but only int, this is quite easy.
- (to exchange more complicated types, see \ref GRAS_dd or
+ involve any newly created types but only int, this is quite easy.
+ (to exchange more complicated types, see \ref GRAS_dd or
\subsection GRAS_ex_ping_serdata 2.a) The server's globals
In order to ensure the communication between the "main" and the callback
\subsection GRAS_ex_ping_serdata 2.a) The server's globals
In order to ensure the communication between the "main" and the callback
\subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
Here is the callback run when the server receives any ping message (this
will be registered later by the server).
\subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
Here is the callback run when the server receives any ping message (this
will be registered later by the server).
\skip server_cb_ping_handler
\until end_of_server_cb_ping_handler
\subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
\skip server_cb_ping_handler
\until end_of_server_cb_ping_handler
\subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
This is the "main" of the server. As explained in the tutorial, \ref
GRAS_tut_tour_setup, you must not write any main()
function yourself. Instead, you just have to write a regular function
like this one which will act as a main.
This is the "main" of the server. As explained in the tutorial, \ref
GRAS_tut_tour_setup, you must not write any main()
function yourself. Instead, you just have to write a regular function
like this one which will act as a main.
This function is quite straightforward, and the inlined comments should
be enough to understand it.
This function is quite straightforward, and the inlined comments should
be enough to understand it.
only one having it. So, if there is an action you want all processes to
do alternativly, but you cannot afford to have two processes doing it at
the same time, let the process having the token doing it.
only one having it. So, if there is an action you want all processes to
do alternativly, but you cannot afford to have two processes doing it at
the same time, let the process having the token doing it.
Actually, there is a lot of different token ring algorithms in the
litterature, so this example implements one of them: the simplest one.
The ring is static (no new node can join it, and you'll get trouble if
one node dies or leaves), and nothing is done for the case in which the
Actually, there is a lot of different token ring algorithms in the
litterature, so this example implements one of them: the simplest one.
The ring is static (no new node can join it, and you'll get trouble if
one node dies or leaves), and nothing is done for the case in which the
The neighbour of each node is given at startup as command line argument.
Moreover, one of the nodes is instructed by a specific argument (the one
on Tremblay here) to create the token at the begining of the algorithm.
The neighbour of each node is given at startup as command line argument.
Moreover, one of the nodes is instructed by a specific argument (the one
on Tremblay here) to create the token at the begining of the algorithm.
The token is incarned by a specific message, which circulates from node
to node (the payload is an integer incremented at each hop). So, the most
important part of the code is the message callback, which forwards the
message to the next node. That is why we have to store all variable in a
The token is incarned by a specific message, which circulates from node
to node (the payload is an integer incremented at each hop). So, the most
important part of the code is the message callback, which forwards the
message to the next node. That is why we have to store all variable in a
\skip node_cb_stoken_handler
\until end_of_node_cb_stoken_handler
\section GRAS_ex_stoken_main 4) The main function
\skip node_cb_stoken_handler
\until end_of_node_cb_stoken_handler
\section GRAS_ex_stoken_main 4) The main function
- This example implements a remote matrix multiplication. It involves a client
- (creating the matrices and sending the multiplications requests) and a server
+ This example implements a remote matrix multiplication. It involves a client
+ (creating the matrices and sending the multiplications requests) and a server
- This example also constitutes a more advanced example of data description
- mechanisms, since the message payload type is a bit more complicated than in
+ This example also constitutes a more advanced example of data description
+ mechanisms, since the message payload type is a bit more complicated than in
other examples such as the ping one (\ref GRAS_ex_ping).
It works the following way (not very different from the ping example):
- Both the client and the server register all needed messages and datatypes
- The server registers a callback to the "request" message, which computes
what needs to be and returns the result to the expeditor.
other examples such as the ping one (\ref GRAS_ex_ping).
It works the following way (not very different from the ping example):
- Both the client and the server register all needed messages and datatypes
- The server registers a callback to the "request" message, which computes
what needs to be and returns the result to the expeditor.
This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
the \ref GRAS_tut_tour_setup of the tutorial if wondering why both the server
and the client live in the same source file)
This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file. (See
the \ref GRAS_tut_tour_setup of the tutorial if wondering why both the server
and the client live in the same source file)
- \ref GRAS_ex_mmrpc_client
- \ref GRAS_ex_mmrpc_cliinc
- \ref GRAS_ex_mmrpc_climain
- \ref GRAS_ex_mmrpc_client
- \ref GRAS_ex_mmrpc_cliinc
- \ref GRAS_ex_mmrpc_climain
\subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
This loads the gras header and declare the function's prototypes as well
\subsection GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
This loads the gras header and declare the function's prototypes as well
Let's first load the module header and declare a logging category (see
\ref XBT_log for more info on logging). This logging category does live
in this file (ie the required symbols are defined here and declared as
Let's first load the module header and declare a logging category (see
\ref XBT_log for more info on logging). This logging category does live
in this file (ie the required symbols are defined here and declared as
- "extern" in any other file using them). That is why we use
- \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
+ "extern" in any other file using them). That is why we use
+ \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
\dontinclude gras/mmrpc/mmrpc_common.c
\skip include
\until XBT_LOG
\subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
\dontinclude gras/mmrpc/mmrpc_common.c
\skip include
\until XBT_LOG
\subsection GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
This function, called by both the client and the server is in charge of
declaring the existing messages to GRAS.
This function, called by both the client and the server is in charge of
declaring the existing messages to GRAS.
All module symbols live in the mmrpc_common.c file. We thus have to
define \ref XBT_DEFINE_TYPE_EXTERN to the preprocessor so that the
All module symbols live in the mmrpc_common.c file. We thus have to
define \ref XBT_DEFINE_TYPE_EXTERN to the preprocessor so that the
\subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
Here is the callback run when the server receives any mmrpc message (this
\subsection GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
Here is the callback run when the server receives any mmrpc message (this
- will be registered later by the server). Note the way we get the message
- payload. In the ping example, there was one additional level of pointer
+ will be registered later by the server). Note the way we get the message
+ payload. In the ping example, there was one additional level of pointer
indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
an array here (ie a pointer) whereas it is a scalar in the ping example.
indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
an array here (ie a pointer) whereas it is a scalar in the ping example.
\skip server_cb_request_handler
\until end_of_server_cb_request_handler
\subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
\skip server_cb_request_handler
\until end_of_server_cb_request_handler
\subsection GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
This is the "main" of the server. As explained in the tutorial, \ref
GRAS_tut_tour_setup, you must not write any main()
function yourself. Instead, you just have to write a regular function
like this one which will act as a main.
This is the "main" of the server. As explained in the tutorial, \ref
GRAS_tut_tour_setup, you must not write any main()
function yourself. Instead, you just have to write a regular function
like this one which will act as a main.
As for the server, some extra love is needed to make sure that automatic
datatype parsing and log categories do work even if we are using several
As for the server, some extra love is needed to make sure that automatic
datatype parsing and log categories do work even if we are using several
\dontinclude gras/mmrpc/mmrpc_client.c
\skip define
\until XBT_LOG
\subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
\dontinclude gras/mmrpc/mmrpc_client.c
\skip define
\until XBT_LOG
\subsection GRAS_ex_mmrpc_climain 3.b) Client's "main" function
This function is quite straightforward, and the inlined comments should
be enough to understand it.
This function is quite straightforward, and the inlined comments should
be enough to understand it.
This example fools around with the GRAS timers (\ref GRAS_timer). It is
mainly a regression test, since it uses almost all timer features.
This example fools around with the GRAS timers (\ref GRAS_timer). It is
mainly a regression test, since it uses almost all timer features.
The main program registers a repetititive task and a delayed one, and
then loops until the <tt>still_to_do</tt> variables of its globals reach
0. The delayed task set it to 5, and the repetititive one decrease it
The main program registers a repetititive task and a delayed one, and
then loops until the <tt>still_to_do</tt> variables of its globals reach
0. The delayed task set it to 5, and the repetititive one decrease it