[contributed by Sékou Diakite, many thanks]
GRAS:
- * Introduce a listener thread in charge of receiving incomming
+ * Introduce a listener thread in charge of receiving incoming
messages from the network. It allows to overlap communication and
computation but most notably, it removes some stupid deadlocks due
to the fact that so far, a process could not send and receive at
EXAMPLE_PATTERNS =
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude
+# searched for input files to be used with the \include or \don'tinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
- loading the platforme/deployment XML file that describe the environment of simulation
- and … Running the Simulation.
-\dontinclude lua/masterslave/master.lua
+\don'tinclude lua/masterslave/master.lua
\subsection bindings_binding_lua_example_master_slave Master/Slave Example
\li Master Code
then simgrid.Task.send(task,alias) to send it.
we use also simgrid.Task.name(task), to get the task's name.
-\dontinclude lua/masterslave/slave.lua
+\don'tinclude lua/masterslave/slave.lua
\li Slave Code
\until end_of_slave
Here, we see the use of simgrid.Task.recv(alias) to receive a task with a specific alias,
this function return directly the task recevied.
-\dontinclude lua/masterslave/master_slave.lua
+\don'tinclude lua/masterslave/master_slave.lua
\li Set Environmenet and run application
\until simgrid.clean()
messages during the transition associated to this event.\n
\n
Incoming messages are not handled as soon as they arrive, but only when
- the process declares to be ready to accept incomming events (using \ref
+ the process declares to be ready to accept incoming events (using \ref
gras_msg_handle or related functions). It ensures that the treatment of a
given message won't run in parallel to any other callback, so that
process globals (its state) can be accessed and modified without
\n
Processes can also wait explicitely for incoming messages matching some
given criterions (using \ref gras_msg_wait). Any messages received before the
- one matching the criterions will be added to the incomming messages'
+ one matching the criterions will be added to the incoming messages'
queue for further use. This may breaks the message delivery order.
Moreover, there is no restriction on when this can be done. So, a
callback to a given message can consume messages of other types. There is
<li>Process A sends a first message (depicted in red) with gras_msg_send(), do
some more computation, and then send another message (depicted in
- yellow). Then, this process handles any incomming message with
+ yellow). Then, this process handles any incoming message with
gras_msg_handle(). Since no message is already queued in process A at this
point, this is a blocking call until the third message (depicted in
magenta) arrives from the other process.</li>
<li>On its side, the process B explicitely wait for the second message with
gras_msg_wait(), do some computation with it, and then call
- gras_msg_handle() to handle any incomming message. This will pop the red
+ gras_msg_handle() to handle any incoming message. This will pop the red
message from the queue, and start the callback attached to that kind of
messages. This callback sends back a new message (depicted in magenta) back
to process A.</li>
from the receiver point of view.</li>
<li>gras_msg_wait() and gras_msg_handle() accept timeouts as argument to
-specify how long you are willing to wait at most for incomming messages. These
+specify how long you are willing to wait at most for incoming messages. These
were ignored here to not complexify the example any further. It is worth
mentionning that the send operation cannot be timeouted. The existance of the
listener should make it useless.</li>
\subsection GRAS_tut_intro_model_timing_policy Timing policy
All communication primitives allow 3 timout policies: one can only poll for
-incomming events (using timeout=0), wait endlessly for the communication to
+incoming events (using timeout=0), wait endlessly for the communication to
be performed (using timeout<0) or specify a maximal delay to wait for the
communication to proceed (using timeout>0, being a number of seconds).
We won't convey any payload in this lesson, so we just have to give the name
of message to declare them:
-\dontinclude 02-simple.c
+\don'tinclude 02-simple.c
\skip gras_msgtype_declare
\until gras_msgtype_declare
\ref gras_socket_client with the hostname and the port of the process you
want to contact as arguments. Our client should simply do:
-\dontinclude 02-simple.c
+\don'tinclude 02-simple.c
\skip socket_client
\until socket_client
message, the message type (described by its name), and a pointer to the actual content of the
message. Since we don't have any payload, this becomes:
-\dontinclude 02-simple.c
+\don'tinclude 02-simple.c
\skip msg_send
\until msg_send
Since our server is willing to wait up to 60 seconds for a message, the
following will do it:
-\dontinclude 02-simple.c
+\don'tinclude 02-simple.c
\skip msg_wait
\until msg_wait
In RL, the situation is quite simple: we just have to use the command line
arguments as we would do in a usual C program. In the server, only change
concern the opennong of the master socket:
-\dontinclude 03-args.c
+\don'tinclude 03-args.c
\skip gras_socket_server
\until gras_socket_server
The callback returns an integer being its error code, just like the "main()"
function. Here is the actual code of our callback:
-\dontinclude 04-callback.c
+\don'tinclude 04-callback.c
\skip gras_msg_cb_ctx_t
\until end_of_callback
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
What we want here is a root category (it does not belong to any existing
channel, for sure), and we want it to be the default one in our file (of
course, it's the only one).
-\dontinclude 06-logs.c
+\don'tinclude 06-logs.c
\skip XBT_LOG
\until XBT_LOG
It is important to note that timers are not prehemptive. They will not start
as soon as they are ready. Instead, they get served when you go into
-gras_msg_handle() (and they are served before incomming messages). This is
+gras_msg_handle() (and they are served before incoming messages). This is
because allowing timers to run in parallel to the callbacks would add
parallelism to the user code, which would have to protect data with mutexes.
This is a level of complexity I really don't want for user code. If you
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:
-\dontinclude 07-timers.c
+\don'tinclude 07-timers.c
\skip client_data
\until client_data_t
periodicity at which it was desinstalled (so that the same action can be
scheduled at different intervals, and each of them be desinstallable
separately).
-\dontinclude 07-timers.c
+\don'tinclude 07-timers.c
\skip gras_timer_cancel_repeat
\until gras_timer_cancel_repeat
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().
-\dontinclude 07-timers.c
+\don'tinclude 07-timers.c
\skip client_do_stop
\until end_of_client_do_stop
kill message to each ports of the search range. If it manage to close the
socket after sending the message without being interrupted by an exception,
it can assume that it killed the server and stop searching.
-\dontinclude 08-exceptions.c
+\don'tinclude 08-exceptions.c
\skip port=3000
\until end_of_loop
look like when it's not catched), we add a potential command line argument
to the server, asking it to cheat and to not open its port within the search
range but elsewhere:
-\dontinclude 08-exceptions.c
+\don'tinclude 08-exceptions.c
\skip strcmp
\until gras_socket_my_port
\until }
the client don't attach any). Here is the message declaring function in our
case:
-\dontinclude 09-simpledata.c
+\don'tinclude 09-simpledata.c
\skip message_declaration(void)
\until }
<tt>(double*)</tt>, and then dereference the obtained pointer by adding a
star before the cast. This is what we do here:
-\dontinclude 09-simpledata.c
+\don'tinclude 09-simpledata.c
\skip server_kill_cb
\until delay
output for the a2i conversion (a=char 2=to i=integer), and the contrary in
the other direction.
-\dontinclude 10-rpc.c
+\don'tinclude 10-rpc.c
\skip gras_msgtype_declare_rpc
\until long
\until string
Here, there is no payload attached to the messages.
-\dontinclude 11-explicitwait.c
+\don'tinclude 11-explicitwait.c
\skip message_declaration
\until }
The core of our distributed service is implemented (protocol, actions on
server side, and accessing function on client side). We should now
-initialize the server and let it wait for incomming messages.
+initialize the server and let it wait for incoming messages.
Defining when to stop the server can become tricky. The simplest solution is
to never let the server stop. It simply runs forever. But the simulator will
Here, we will just hardcode that the clients ask 5 times for the token, and
that there is two clients. This clearly simplify the problem.
-\dontinclude 11-explicitwait.c
+\don'tinclude 11-explicitwait.c
\skip gras_userdata_new
\until gras_msg_handle
to attach a callback to the message. Of course, you usualy don't want to do
so on every nodes, but only on "servers" or "workers" or such. First of all,
you need to declare the callback itself. This function that will be executed
-on request incomming must follow a very specific prototype (the same
+on request incoming must follow a very specific prototype (the same
regardless of the call semantic):
\verbatim
<hr>
- \dontinclude gras/ping/ping_common.c
+ \don'tinclude gras/ping/ping_common.c
\section GRAS_ex_ping_common 1) Common code to the client and the server
The module header <tt>ping.h</tt> reads:
- \dontinclude gras/ping/ping.h
+ \don'tinclude gras/ping/ping.h
\skip include
\until argv
\until argv
(to exchange more complicated types, see \ref GRAS_dd or
\ref GRAS_ex_mmrpc for an example).
- \dontinclude gras/ping/ping_common.c
+ \don'tinclude gras/ping/ping_common.c
\skip register_messages
\until }
struct definition so that they can be handled properly in GRAS (see the
\ref GRAS_tut_tour_globals for more info).
- \dontinclude gras/ping/ping_server.c
+ \don'tinclude gras/ping/ping_server.c
\skip typedef struct
\until }
This function is quite straightforward, and the inlined comments should
be enough to understand it.
- \dontinclude gras/ping/ping_client.c
+ \don'tinclude gras/ping/ping_client.c
\skip client
\until end_of_client
message to the next node. That is why we have to store all variable in a
global, as explained in the \ref GRAS_globals section.
- \dontinclude examples/gras/mutual_exclusion/simple_token/simple_token.c
+ \don'tinclude examples/gras/mutual_exclusion/simple_token/simple_token.c
\skip typedef
\until }
This loads the gras header and declare the function's prototypes as well
as the matrix size.
- \dontinclude gras/mmrpc/mmrpc.h
+ \don'tinclude gras/mmrpc/mmrpc.h
\skip include
\until argv
\until argv
\ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
\ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
- \dontinclude gras/mmrpc/mmrpc_common.c
+ \don'tinclude gras/mmrpc/mmrpc_common.c
\skip include
\until XBT_LOG
\ref XBT_DEFINE_TYPE symbols don't get included here. Likewise, we use
\ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
- \dontinclude gras/mmrpc/mmrpc_server.c
+ \don'tinclude gras/mmrpc/mmrpc_server.c
\skip define
\until XBT_LOG
datatype parsing and log categories do work even if we are using several
files.
- \dontinclude gras/mmrpc/mmrpc_client.c
+ \don'tinclude gras/mmrpc/mmrpc_client.c
\skip define
\until XBT_LOG
This function is quite straightforward, and the inlined comments should
be enough to understand it.
- \dontinclude gras/mmrpc/mmrpc_client.c
+ \don'tinclude gras/mmrpc/mmrpc_client.c
\skip argv
\until end_of_client
- \ref GRAS_ex_timer_repeat
- \ref GRAS_ex_timer_main
- \dontinclude timer.c
+ \don'tinclude timer.c
\section GRAS_ex_timer_decl 1. Declarations and headers
\skip include
<hr>
-\dontinclude msg/icomms/peer.c
+\don'tinclude msg/icomms/peer.c
\section MSG_ext_icomms_code Code of the application
\until end_of_main
-\dontinclude msg/icomms/peer2.c
+\don'tinclude msg/icomms/peer2.c
\section MSG_ext_icomms_fct_Waitall Waitall function for sender
\subsection MSG_ext_icomms_fct_Waitany_sender From a sender
We can use this function to wait all sent messages.
-\dontinclude msg/icomms/peer3.c
+\don'tinclude msg/icomms/peer3.c
\skipline Sender function
\until end_of_sender
\subsection MSG_ext_icomms_fct_Waitany_receiver From a receiver
We can also wait for the arrival of all messages.
-\dontinclude msg/icomms/peer3.c
+\don'tinclude msg/icomms/peer3.c
\skipline Receiver function
\until end_of_receiver
<hr>
-\dontinclude msg/masterslave/masterslave_forwarder.c
+\don'tinclude msg/masterslave/masterslave_forwarder.c
\section MSG_ext_ms_code Code of the application
- \ref MSG_ext_ms_platform
- \dontinclude lua/masterslave/master_slave.lua
+ \don'tinclude lua/masterslave/master_slave.lua
\section MSG_ext_ms_code_lua Code of the application
- \ref MSG_ext_ms_core_lua
- \dontinclude lua/console/master_slave_bypass.lua
+ \don'tinclude lua/console/master_slave_bypass.lua
\section MSG_ext_ms_code_lua Code of the application
2 2 0 1 0 7 250 -1 20 0.000 0 0 -1 0 0 5
21555 3870 19125 3870 19125 7470 21555 7470 21555 3870
4 0 0 240 -1 0 12 0.0000 2 90 435 19260 4635 name\001
-4 0 0 240 -1 0 12 0.0000 2 180 2385 19260 7110 incomming_communications\001
+4 0 0 240 -1 0 12 0.0000 2 180 2385 19260 7110 incoming_communications\001
4 0 0 240 -1 0 12 0.0000 2 180 2205 19260 7335 outgoing_communications\001
4 0 0 240 -1 0 12 0.0000 2 135 165 19260 6885 id\001
4 0 0 240 -1 0 12 0.0000 2 180 1200 19260 4410 type (cpu|link)\001
xbt_socket_my_port(globals->sock));
globals->endcondition = 0;
- /* 6. Wait up to 20 minutes for an incomming message to handle */
+ /* 6. Wait up to 20 minutes for an incoming message to handle */
gras_msg_handle(20.0);
/* 7. Housekeeping */
/* 5. Register my callback */
gras_cb_register("request", &server_cb_request_handler);
- /* 6. Wait up to 10 minutes for an incomming message to handle */
+ /* 6. Wait up to 10 minutes for an incoming message to handle */
gras_msg_handle(600.0);
/* 7. Free the allocated resources, and shut GRAS down */
XBT_INFO("Launch server (port=%d)", port);
sock = try_gras_socket_server(port);
- /* 6. Wait up to 10 minutes for an incomming message to handle */
+ /* 6. Wait up to 10 minutes for an incoming message to handle */
gras_msg_handle(600.0);
/* 7. Free the allocated resources, and shut GRAS down */
}
}
- /* 8. Wait up to 10 seconds for an incomming message to handle */
+ /* 8. Wait up to 10 seconds for an incoming message to handle */
while (globals->remaining_loop > (globals->create ? -1 : 0)) {
gras_msg_handle(-1);
xbt_socket_my_port(globals->sock));
globals->endcondition = 0;
- /* 6. Wait up to 10 minutes for an incomming message to handle */
+ /* 6. Wait up to 10 minutes for an incoming message to handle */
gras_msg_handle(10.0);
/* 7. Housekeeping */
XBT_INFO("Listening on port %d", xbt_socket_my_port(mysock));
- /* 5. Wait for the ping incomming messages */
+ /* 5. Wait for the ping incoming messages */
/** \bug if the server is gone before the forwarder tries to connect,
it dies awfully with the following message. The problem stands somewhere
<process host="Bourassa" function="replace">
<argument value="Calling replace() from Bourassa"/>
</process>
- <process host="Jupiter" function="please_dont_replace_me">
- <argument value="Calling please_dont_replace_me() from Jupiter"/>
+ <process host="Jupiter" function="please_don't_replace_me">
+ <argument value="Calling please_don't_replace_me() from Jupiter"/>
</process>
</platform>
print_global()
end
--- Replaces the function please_dont_change_me() by set_global_string()
+-- Replaces the function please_don't_change_me() by set_global_string()
-- and calls it
function replace(...)
- simgrid.info("Overwriting function please_dont_replace_me()")
- please_dont_replace_me = set_global_string
- please_dont_replace_me(...)
+ simgrid.info("Overwriting function please_don't_replace_me()")
+ please_don't_replace_me = set_global_string
+ please_don't_replace_me(...)
end
-- Shows a hello message and prints the global string
-function please_dont_replace_me(...)
+function please_don't_replace_me(...)
- simgrid.info("Hello from please_dont_replace_me(). I'm lucky, I still exist in this state.")
+ simgrid.info("Hello from please_don't_replace_me(). I'm lucky, I still exist in this state.")
print_global()
end
> [0.000000] [lua/INFO] Global string is 'A global string set by maestro'
> [Tremblay:set_global_string:(1) 0.000000] [lua/INFO] Changing the global string
> [Tremblay:set_global_string:(1) 0.000000] [lua/INFO] Global string is 'Calling set_global_string() from Tremblay'
-> [Bourassa:replace:(2) 0.000000] [lua/INFO] Overwriting function please_dont_replace_me()
+> [Bourassa:replace:(2) 0.000000] [lua/INFO] Overwriting function please_don't_replace_me()
> [Bourassa:replace:(2) 0.000000] [lua/INFO] Changing the global string
> [Bourassa:replace:(2) 0.000000] [lua/INFO] Global string is 'Calling replace() from Bourassa'
-> [Jupiter:please_dont_replace_me:(3) 0.000000] [lua/INFO] Hello from please_dont_replace_me(). I'm lucky, I still exist in this state.
-> [Jupiter:please_dont_replace_me:(3) 0.000000] [lua/INFO] Global string is 'A global string set by maestro'
+> [Jupiter:please_don't_replace_me:(3) 0.000000] [lua/INFO] Hello from please_don't_replace_me(). I'm lucky, I still exist in this state.
+> [Jupiter:please_don't_replace_me:(3) 0.000000] [lua/INFO] Global string is 'A global string set by maestro'
* @hideinitializer
* @param timeout: How long should we wait for this message.
* @param msgt_want: type of awaited msg
- * @param[out] expeditor: where to create a socket to answer the incomming message
- * @param[out] payload: where to write the payload of the incomming message
+ * @param[out] expeditor: where to create a socket to answer the incoming message
+ * @param[out] payload: where to write the payload of the incoming message
* @return the error code (or no_error).
*
* Every message of another type received before the one waited will be queued
* right answer from the right host and so on. Any exception raised on the
* server is also passed over the network to the client.
*
- * Callbacks are attached to RPC incomming messages the regular way using
+ * Callbacks are attached to RPC incoming messages the regular way using
* \ref gras_cb_register.
*
* For an example of use, check the examples/gras/rpc directory of the distribution.
group communication
*/
- e_gras_msg_kind_count = 5 /* sentinel, dont mess with */
+ e_gras_msg_kind_count = 5 /* sentinel, don't mess with */
} e_gras_msg_kind_t;
* and such within a specific process.
*
* Timers are served by the gras_handle() function: if there is an elapsed
- * timer, the associated code gets executed before any incomming connexion
+ * timer, the associated code gets executed before any incoming connexion
* are checked.
*
* The section \ref GRAS_ex_timer constitutes a perfect example of these features.
*
* \section XBT_cfg_ex Example of use
*
- * \dontinclude config.c
+ * \don'tinclude config.c
*
* First, let's create a configuration set with some registered variables.
* This must be done by the configurable library before the user interactions.
/* @{ */
-/** \brief Opaque type describing a type description callback persistant state. */
+/** \brief Opaque type describing a type description callback persistent state. */
typedef struct s_xbt_cbps *xbt_cbps_t;
/* callbacks prototypes */
* structure creation (of type void_f_ppvoid_t or void_f_pvoid_t).
*
* \section XBT_dynar_exscal Example with scalar
- * \dontinclude dynar.c
+ * \don'tinclude dynar.c
*
* \skip Vars_decl
* \skip dyn
* following code which shows some pitfalls and contains many errors (assuming
* a mallocex() function which throws an exception if malloc(3) fails):
*
- * \dontinclude ex.c
+ * \don'tinclude ex.c
* \skip BAD_EXAMPLE
* \until end_of_bad_example
*
*/
static int msg_register_platform(lua_State * L)
{
- /* Tell Simgrid we dont wanna use its parser */
+ /* Tell Simgrid we don't wanna use its parser */
//surf_parse = console_parse_platform;
surf_parse_reset_callbacks();
MSG_create_environment(NULL);
*
* @param timeout: How long should we wait for this message.
* @param msgt_want: type of awaited msg
- * @param[out] expeditor: where to create a socket to answer the incomming message
- * @param[out] payload: where to write the payload of the incomming message
+ * @param[out] expeditor: where to create a socket to answer the incoming message
+ * @param[out] payload: where to write the payload of the incoming message
* @return the error code (or no_error).
*
* Every message of another type received before the one waited will be queued
* @param msgt_want: a dynar containing all accepted message type
* @param[out] ctx: the context of received message (in case it's a RPC call we want to answer to)
* @param[out] msgt_got: indice in the dynar of the type of the received message
- * @param[out] payload: where to write the payload of the incomming message
+ * @param[out] payload: where to write the payload of the incoming message
* @return the error code (or no_error).
*
* Every message of a type not in the accepted list received before the one
} while (period - now + begin > 0);
}
-/** @brief Handle an incomming message or timer (or wait up to \a timeOut seconds)
+/** @brief Handle an incoming message or timer (or wait up to \a timeOut seconds)
*
* @param timeOut: How long to wait for incoming messages (in seconds)
* @return the error code (or no_error).
volatile unsigned int cpt2 = cpt;
if (!ran_ok) {
XBT_DEBUG
- ("Use the callback #%u (@%p) for incomming msg '%s' (payload_size=%d)",
+ ("Use the callback #%u (@%p) for incoming msg '%s' (payload_size=%d)",
cpt + 1, cb, msg.type->name, msg.payl_size);
if (!cb(&ctx, msg.payl)) {
/* cb handled the message */
typedef struct s_gras_msg_listener_ {
xbt_thread_t listener; /* keep this first, gras_socket_im_the_server() does funky transtyping in sg_msg.c */
- xbt_queue_t incomming_messages; /* messages received from the wire and still to be used by master */
+ xbt_queue_t incoming_messages; /* messages received from the wire and still to be used by master */
xbt_queue_t socks_to_close; /* let the listener close the sockets, since it may be selecting on them. Darwin don't like this trick */
xbt_socket_t wakeup_sock_listener_side;
xbt_socket_t wakeup_sock_master_side;
I'm not the user process but I'm just the listener. Too bad */
XBT_VERB("Got a '%s' message (%s) from sock %p. Queue it for handling by main thread",
gras_msgtype_get_name(msg->type),e_gras_msg_kind_names[msg->kind],msg->expe);
- xbt_queue_push(me->incomming_messages, msg);
+ xbt_queue_push(me->incoming_messages, msg);
} else {
char got = *(char *) msg->payl;
if (got == '1') {
gras_msg_listener_t arg = xbt_new0(s_gras_msg_listener_t, 1);
XBT_VERB("Launch listener");
- arg->incomming_messages = msg_received;
+ arg->incoming_messages = msg_received;
arg->socks_to_close = xbt_queue_new(0, sizeof(int));
arg->init_mutex = xbt_mutex_init();
arg->init_cond = xbt_cond_init();
xbt_thread_join(pd->listener->listener);
// gras_socket_close(pd->listener->wakeup_sock_master_side); FIXME: uncommenting this leads to deadlock at terminaison
- xbt_queue_free(&pd->listener->incomming_messages);
+ xbt_queue_free(&pd->listener->incoming_messages);
xbt_queue_free(&pd->listener->socks_to_close);
xbt_free(pd->listener);
}
int pid; /* pid of process, only for SG */
int ppid; /* ppid of process, only for SG */
- gras_msg_listener_t listener; /* the thread in charge of the incomming communication for this process */
+ gras_msg_listener_t listener; /* the thread in charge of the incoming communication for this process */
} gras_procdata_t;
gras_procdata_t *gras_procdata_get(void);
}
}
- XBT_DEBUG("Min for resources (remember that NS3 dont update that value) : %f", min);
+ XBT_DEBUG("Min for resources (remember that NS3 don't update that value) : %f", min);
XBT_DEBUG("Looking for next trace event");
-/* cbps - persistant states for callbacks */
+/* cbps - persistent states for callbacks */
/* Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010. The SimGrid Team.
* All rights reserved. */
#include "xbt/ex.h"
#include "xbt/datadesc/datadesc_private.h"
XBT_LOG_NEW_DEFAULT_SUBCATEGORY(xbt_ddt_cbps, xbt_ddt,
- "callback persistant state");
+ "callback persistent state");
typedef struct {
xbt_datadesc_type_t type;
enum e_xbt_dd_scalar_encoding encoding);
/****************************************************
- * Callback persistant state constructor/destructor *
+ * Callback persistent state constructor/destructor *
****************************************************/
xbt_cbps_t xbt_cbps_new(void);
void xbt_cbps_free(xbt_cbps_t * state);
cpp = cpp->nextSibling;
}
- XBT_DEBUG("Childs of %s: %s; nextSibling: %s",
+ XBT_DEBUG("Children of %s: %s; nextSibling: %s",
category->parent->name, res,
(category->parent->nextSibling ?
category->parent->nextSibling->name : "none"));