X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/3d0d626e19a7b79320e7d922c9c1dcf122076cea..8aaf488a3efac91cd28691c832e0b084c83f2e95:/cruft/doc/tmpl/gras-unused.sgml
diff --git a/cruft/doc/tmpl/gras-unused.sgml b/cruft/doc/tmpl/gras-unused.sgml
index c26a9bf998..13fc99c080 100644
--- a/cruft/doc/tmpl/gras-unused.sgml
+++ b/cruft/doc/tmpl/gras-unused.sgml
@@ -136,6 +136,26 @@ Describing the data
DataDescriptor API
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dynamic arrays
+
+
@@ -276,335 +296,1231 @@ Data description callbacks persistant state
config
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Data description callbacks persistant state
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Implementation of data description
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+dico
+
+
+
+
+This module provide the quite usual dynamic array facility.
+
+
+
+
+
+
+
+
+
+
+Dynamic array
+
+
+
+dynar
+
+
+
+ This document introduce the GRAS library (Grid Reality
+ And Simulation, or according to my english dictionary,
+ Generally Recognized As Safe ;).
+
+
+ Overview
+ The purpose of the GRAS is to allow the developpement of
+ distributed programs which will work with as few as possible
+ modification both on the SimGrid simulator (SG), and in the Real Life
+ (RL).
+
+ Here are the problems when you want to do so:
+
+
+ Communication in SG is done by passing tasks, while in
+ RL, you have to deal with sockets (or any wrapper to it).
+
+ In RL, each process should provide a main()
+ function, and it's obviously not the case in SG.
+
+
+
+
+
+ Application class target
+ If you want to run your code both in RL and in SG, you won't be
+ able to use the full set of features offered by any of those two
+ worlds. GRAS tries to provide a suffisent set of features to develop
+ your application, and implement them in both worlds.
+
+ GRAS uses the paradigm of event-driven
+ programming, which is an extension to the message-passing
+ one. Any process of a typical event-driven application declares
+ callback to incoming events, which can be messages from other
+ processes, timers or others.
+
+ All messages have an header, specifying its type, and attached
+ data, represented as one or several C structures. In order to send
+ the data over the network in RL, a type-description mecanism is
+ provided, and the RL version of GRAS implements CDR
+ functionnalities. That is to say that the data are sent in the native
+ format of the sender host, and converted on the destination host only
+ if needed.
+
+ In order to not reimplement the wheel, GRAS use existing code,
+ and adapt them to make them work together. The SG version naturally
+ use the SimGrid toolkit, while the RL version is based over the
+ communication library used in NWS (note that this library was somehow
+ modified, since the previous version use XDR, ie both the sender and
+ the receiver convert the data from/to a so called network
+ format). That's why some basic knowledge about how NWS work is
+ supposed in this document. But don't worry, you only have to know the
+ basics about NWS, the internals needed to understand the document
+ will be presented when needed.
+
+
+
+
+
+
+
+
+
+
+Overview of the GRAS library
+
+
+
+Overview
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt.sgml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+./gras-sections.txt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+gras
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+gras_private
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Implementation of GRAS suited for real life.
+
+
+
+RL
+
+
+
+
+ SimGrid was designed to ease the comparison of algorithms and
+ heuristics. That way, a lot of complicated notion from the system layer
+ were volontary left off. For example, migrating a process from an host to
+ another is as easy as: MSG_process_change_host(process, new_host).
+
+
+
+ No need to tell that performing this operation on real platform is really
+ harder. This simplification is a very good thing when you want to rapidly
+ prototype code, but makes things somehow more complicated in GRAS since
+ we want to have a realistic API, since it have to be implemented in
+ reality also.
+
+
+
+ The best example of complexity in GRAS_SG induced by simplicity in
+ SimGrid is the sockets handling. There is no "socket" in SG, but only
+ m_channel_t. In contrary to sockets from RL, no special treatment is
+ needed for a process before writing or reading on/from a channel. So, a
+ given channel can be pooled by more than one process. Likewise, you can
+ send data to a channel that nobody is actually listening to.
+
+
+
+ The SG implementation of GRAS repport as an error the fact that nobody is
+ listening to the socket when trying to open a socket, or send stuff using
+ a previously openned socket. That way, the SG version can be used to
+ debug all syncronization issues. For that, we store mainly the PID of
+ both the sender and the receiver in the socket structure, and then
+ resolve PID->process at the lastest moment. This search is a bit
+ expensive, but as long as there is no real garbage collection in SG, with
+ the information "dead process" within the structure, it's the only
+ solution to make sure that we won't dereference pointers to an old freed
+ structure when the process on the other side of the structure did finish
+ since the creation of the socket.
+
+
+
+ As said in the overview, the processes can declare to hear on several
+ sockets, but all incoming messages are handled by the same loop. So, we
+ can use only one channel per process, and use a table on each host to
+ determine to which process a message should be delivered depending on the
+ socket number provided by the sender.
+
+
+
+
+
+RL, the implementation suited for real life.
+
+
+
+
+
+
+Implementation of GRAS on top of the simulator.
+
+
+
+SG
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+nws_comm
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Configuration facilities.
+
+
+
+Config
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Data container associating data to a string key.
+
+
+
+Dictionnary
+
+
+
+
+This module provide the quite usual dynamic array facility.
+
+
+
+
+
+
+
+
+
+
+Use arrays, forget about malloc
+
+
+
+Dynamic array
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Error reporting
+
+
+
+Errors handling
+
+
+
+
+ This is an adaptation of the log4c project, which is dead upstream, and which
+ I was given the permission to fork under the LGPL licence by the authors. log4c
+ itself was loosely based on the Apache project's Log4J, Log4CC,
+ etc. project. Because C is not object oriented, a lot had to change.
+
+
+
+ Overview
+
+
+ There is 3 main concepts: category, priority and appender. These three
+ concepts work together to enable developers to log messages according to
+ message type and priority, and to control at runtime how these messages are
+ formatted and where they are reported.
+
+
+
+
+ Category hierarchy
+
+
+ The first and foremost advantage of any logging API over plain printf()
+ resides in its ability to disable certain log statements while allowing
+ others to print unhindered. This capability assumes that the logging space,
+ that is, the space of all possible logging statements, is categorized
+ according to some developer-chosen criteria.
+
+
+
+ This observation led to choosing category as the central concept of the
+ system. Every category is declared by providing a name and an optional
+ parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT
+ is the category's parent.
+
+
+
+ A category is created by a macro call at the top level of a file. A
+ category can be created with any one of the following macros:
+
+
+
+
+ @GRAS_LOG_NEW_CATEGORY(MyCat);
+ create a new root
+
+
+
+ @GRAS_LOG_NEW_SUBCATEGORY(MyCat, ParentCat);
+ Create a new category being child of the category ParentCat
+
+
+
+ @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat);
+ Like GRAS_LOG_NEW_CATEGORY, but the new category is the default one
+ in this file
+
+
+
+ @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat);
+ Like GRAS_LOG_NEW_SUBCATEGORY, but the new category is the default one
+ in this file
+
+
+
+
+ The parent cat can be defined in the same file or in another file, but each
+ category may have only one definition.
+
+
+
+ Typically, there will be a Category for each module and sub-module, so you
+ can independently control logging for each module.
+
+
+
+
+ Priority
+
+
+ A category may be assigned a threshold priorty. The set of priorites are
+ defined by the @gras_log_priority_t enum. Their values are DEBUG, VERBOSE,
+ INFO, WARNING, ERROR and CRITICAL.
+
+
+
+ If a given category is not assigned a threshold priority, then it inherits
+ one from its closest ancestor with an assigned threshold.
+
+
+
+ To ensure that all categories can eventually inherit a threshold, the root
+ category always has an assigned threshold priority.
+
+
+
+ Logging requests are made by invoking a logging macro on a category. All
+ of the macros have a printf-style format string followed by arguments.
+ Because most C compilers do not support vararg macros, there is a version
+ of the macro for any number of arguments from 0 to 6. The macro name ends
+ with the total number of arguments.
+
+
+
+ Here is an example of the most basic type of macro:
+
+
+ CLOG5(MyCat, gras_log_priority_warning, "Values are: %d and '%s'", 5, "oops");
+
+ This is a logging request with priority WARN.
+
+
+ A logging request is said to be enabled if its priority is higher than or
+ equal to the threshold priority of its category. Otherwise, the request is
+ said to be disabled. A category without an assigned priority will inherit
+ one from the hierarchy.
+
+
+
+ It is possible to use any non-negative integer as a priority. If, as in the
+ example, one of the standard priorites is used, then there is a convenience
+ macro that is typically used instead. For example, the above example is
+ equivalent to the shorter:
+
+
+ CWARN4(MyCat, "Values are: %d and '%s'", 5, "oops");
+
+
+
+ Default category
+
+
+ If @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or
+ @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the category, then
+ the even shorter form can be used:
+
+
+ WARN3("Values are: %d and '%s'", 5, "oops");
+
+
+ Only one default category can be created per file, though multiple
+ non-defaults can be created and used.
+
+
+
+
+ Example
+
+ Here is a more complete example:
+
+
+ #include "gras.h"
+
+ /* create a category and a default subcategory */
+ GRAS_LOG_NEW_CATEGORY(VSS);
+ GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS);
+
+ main() {
+ /* Now set the parent's priority.
+ (the string would typcially be a runtime option) */
+ gras_log_control_set("SA.thresh=3");
+
+ /* This request is enabled, because WARNING >= INFO. */
+ CWARN2(VSS, "Low fuel level.");
+
+ /* This request is disabled, because DEBUG < INFO. */
+ CDEBUG2(VSS, "Starting search for nearest gas station.");
+
+ /* The default category SA inherits its priority from VSS. Thus,
+ the following request is enabled because INFO >= INFO. */
+ INFO1("Located nearest gas station.");
+
+ /* This request is disabled, because DEBUG < INFO. */
+ DEBUG1("Exiting gas station search");
+ }
+
+
+
+ Configuration
+
+
+ Configuration is typically done during program initialization by invoking
+ the gras_log_control_set() method. The control string passed to it
+ typically comes from the command line. Look at the doucmentation for that
+ function for the format of the control string.
+
+
+
+
+ Performance
+
+
+ Clever design insures efficiency. Except for the first invocation, a
+ disabled logging request requires an a single comparison of a static
+ variable to a constant.
+
+
+
+ There is also compile time constant, @GRAS_LOG_STATIC_THRESHOLD, which
+ causes all logging requests with a lower priority to be optimized to 0 cost
+ by the compiler. By setting it to gras_log_priority_infinite, all logging
+ requests are statically disabled and cost nothing. Released executables
+ might typically be compiled with
+ "-DGRAS_LOG_STATIC_THRESHOLD=gras_log_priority_infinite".
+
+
+
+
+ Appenders
+
+
+ Each category has an optional appender. An appender is a pointer to a
+ structure whcih starts with a pointer to a doAppend() function. DoAppend()
+ prints a message to a log.
+
+
+
+ WHen a category is passed a message by one of the logging macros, the
+ category performs the following actions:
+
+
+
+
+
+ if the category has an appender, the message is passed to the
+ appender's doAppend() function,
+
+
+
+
+
+ if 'willLogToParent' is true for the category, the message is passed
+ to the category's parent.
+
+
+
+ By default, all categories except root have no appender and
+ 'willLogToParent' is true. This situation causes all messages to be
+ logged by the root category's appender.
+
+
+
+ Typically, you would only change the root category's appender when you
+ wanted, say, a different output format. Copying defaultLogAppender.c
+ would be a good start.
+
+
+
+ The default appender function currently prints to stderr, but more
+ would be needed, like the one able to send the logs to a remote
+ dedicated server.
+
+
+
+
+
+
+ Misc and Caveats
+
+
+ Do not use any of the macros that start with '_'.
+
+
+
+ The current set of macros force each file to use categories declared in
+ that file. This is intentional. Make the category a child of the file's
+ module category.
+
+
+
+ Log4J has a 'rolling file appender' which you can select with a run-time
+ option and specify the max file size. This would be a nice default for
+ non-kernel applications.
+
+
+
+ Careful, category names are global variables.
+
+
+
+
+
+
+
+
+
+
+
+An easy-to-use, fast and flexible message logging architecture.
+
+
+
+Logging facilities
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Data storage for very quick retrieve
+
+
+
+Data set
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sockets
+
+
+
-
+
-
+
-
-Data description callbacks persistant state
+
+xbt_cfg
-
+
-
+
-
+
-
-Implementation of data description
+
+xbt_dico
-
+
-
+
-
+
-
-dico
+
+Errors
-
+
-This module provide the quite usual dynamic array facility.
+
-
+
-
-Dynamic array
-
-
-
-dynar
+
-
- This document introduce the GRAS library (Grid Reality
- And Simulation, or according to my english dictionary,
- Generally Recognized As Safe ;).
-
-
- Overview
- The purpose of the GRAS is to allow the developpement of
- distributed programs which will work with as few as possible
- modification both on the SimGrid simulator (SG), and in the Real Life
- (RL).
- Here are the problems when you want to do so:
-
-
- Communication in SG is done by passing tasks, while in
- RL, you have to deal with sockets (or any wrapper to it).
-
- In RL, each process should provide a main()
- function, and it's obviously not the case in SG.
-
-
-
-
-
- Application class target
- If you want to run your code both in RL and in SG, you won't be
- able to use the full set of features offered by any of those two
- worlds. GRAS tries to provide a suffisent set of features to develop
- your application, and implement them in both worlds.
+
+xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml
- GRAS uses the paradigm of event-driven
- programming, which is an extension to the message-passing
- one. Any process of a typical event-driven application declares
- callback to incoming events, which can be messages from other
- processes, timers or others.
- All messages have an header, specifying its type, and attached
- data, represented as one or several C structures. In order to send
- the data over the network in RL, a type-description mecanism is
- provided, and the RL version of GRAS implements CDR
- functionnalities. That is to say that the data are sent in the native
- format of the sender host, and converted on the destination host only
- if needed.
+
+
- In order to not reimplement the wheel, GRAS use existing code,
- and adapt them to make them work together. The SG version naturally
- use the SimGrid toolkit, while the RL version is based over the
- communication library used in NWS (note that this library was somehow
- modified, since the previous version use XDR, ie both the sender and
- the receiver convert the data from/to a so called network
- format). That's why some basic knowledge about how NWS work is
- supposed in this document. But don't worry, you only have to know the
- basics about NWS, the internals needed to understand the document
- will be presented when needed.
-
+
-
+
-
-Overview of the GRAS library
+
-
-Overview
+
+xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml.sgml
-
+
+
-
+
-
+
-
-gras
+
+xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml
-
+
-
+
-
+
-
-gras_private
+
+xbt_swag.sgml.sgml.sgml.sgml.sgml
-
+
-
+
-
-Implementation of GRAS suited for real life.
+
-
-RL
+
+xbt_swag.sgml.sgml.sgml.sgml
-
-
- SimGrid was designed to ease the comparison of algorithms and
- heuristics. That way, a lot of complicated notion from the system layer
- were volontary left off. For example, migrating a process from an host to
- another is as easy as: MSG_process_change_host(process, new_host).
-
+
- No need to tell that performing this operation on real platform is really
- harder. This simplification is a very good thing when you want to rapidly
- prototype code, but makes things somehow more complicated in GRAS since
- we want to have a realistic API, since it have to be implemented in
- reality also.
-
-
- The best example of complexity in GRAS_SG induced by simplicity in
- SimGrid is the sockets handling. There is no "socket" in SG, but only
- m_channel_t. In contrary to sockets from RL, no special treatment is
- needed for a process before writing or reading on/from a channel. So, a
- given channel can be pooled by more than one process. Likewise, you can
- send data to a channel that nobody is actually listening to.
-
- The SG implementation of GRAS repport as an error the fact that nobody is
- listening to the socket when trying to open a socket, or send stuff using
- a previously openned socket. That way, the SG version can be used to
- debug all syncronization issues. For that, we store mainly the PID of
- both the sender and the receiver in the socket structure, and then
- resolve PID->process at the lastest moment. This search is a bit
- expensive, but as long as there is no real garbage collection in SG, with
- the information "dead process" within the structure, it's the only
- solution to make sure that we won't dereference pointers to an old freed
- structure when the process on the other side of the structure did finish
- since the creation of the socket.
-
+
- As said in the overview, the processes can declare to hear on several
- sockets, but all incoming messages are handled by the same loop. So, we
- can use only one channel per process, and use a table on each host to
- determine to which process a message should be delivered depending on the
- socket number provided by the sender.
-
-
-
-
-RL, the implementation suited for real life.
-
+
-
-Implementation of GRAS on top of the simulator.
-
-SG
+
+xbt_swag.sgml.sgml.sgml
-
+
-
+
-
+
-
-nws_comm
+
+xbt_swag.sgml.sgml
-
+
-
+
-
+
-
-Sockets
+
+xbt_swag.sgml
@@ -676,20 +1592,6 @@ Sockets
@a4:
@a5:
-
-
-
-
-
-@c:
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -753,20 +1655,6 @@ Sockets
@a4:
@a5:
-
-
-
-
-
-@c:
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -830,20 +1718,6 @@ Sockets
@a4:
@a5:
-
-
-
-
-
-@c:
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -907,20 +1781,6 @@ Sockets
@a4:
@a5:
-
-
-
-
-
-@c:
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -990,67 +1850,37 @@ Sockets
@a4:
@a5:
-
-
-
-
-
-@c:
-@p:
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
-
-
-
-
-
-@f:
-
-
-
-
-
-
-@f:
-@a1:
-
-
+
+@c:
+@p:
@f:
@a1:
@a2:
+@a3:
+@a4:
+@a5:
+@a6:
-
+
@f:
-@a1:
-@a2:
-@a3:
-
+
@f:
@a1:
-@a2:
-@a3:
-@a4:
-
+
@@ -1058,11 +1888,8 @@ Sockets
@f:
@a1:
@a2:
-@a3:
-@a4:
-@a5:
-
+
@@ -1071,37 +1898,29 @@ Sockets
@a1:
@a2:
@a3:
-@a4:
-@a5:
-@a6:
-
+
-@c:
@f:
@a1:
@a2:
@a3:
@a4:
-@a5:
-@a6:
-
+
-@c:
@f:
@a1:
@a2:
@a3:
@a4:
@a5:
-@a6:
@@ -1158,19 +1977,6 @@ Sockets
@childToParent:
@Returns:
-
-
-
-
-
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -1241,19 +2047,6 @@ Sockets
-
-
-
-
-
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -1273,14 +2066,6 @@ Sockets
@HOST_FORMAT:
@NETWORK_FORMAT:
-
-
-
-
-
-@name:
-@def:
-
@@ -1315,6 +2100,7 @@ Sockets
@catName:
+@desc:
@@ -1322,6 +2108,7 @@ Sockets
@cname:
+@desc:
@@ -1330,6 +2117,7 @@ Sockets
@cname:
@parent:
+@desc:
@@ -1338,6 +2126,7 @@ Sockets
@catName:
@parent:
+@desc:
@@ -1438,19 +2227,6 @@ Sockets
@format:
@Returns:
-
-
-
-
-
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -1750,38 +2526,12 @@ Sockets
@sd:
@Returns:
-
-
-
-
-
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
-
-
-
-
-
-@f:
-@a1:
-@a2:
-@a3:
-@a4:
-@a5:
-@a6:
-
@@ -2099,115 +2849,6 @@ Sockets
@ud:
-
-
-
-
-
-@Returns:
-
-
-
-
-
-
-@msgtype:
-@cb:
-@Returns:
-@message:
-@TTL:
-
-
-
-
-
-
-@expeditor:
-@payload:
-@Returns:
-@payload_type:
-@payload_data:
-@msg:
-
-
-
-
-
-
-@msgtype:
-@cb:
-
-
-
-
-
-
-@ps:
-
-
-
-
-
-
-@ps:
-
-
-
-
-
-
-@ps:
-@Returns:
-
-
-
-
-
-
-@ps:
-@val:
-
-
-
-
-
-
-@ps:
-@name:
-@ddt:
-
-
-
-
-
-
-@ps:
-@name:
-@ddt:
-@res:
-@Returns:
-
-
-
-
-
-
-@ps:
-@name:
-@data:
-@ddt:
-@Returns:
-
-
-
-
-
-
-@ps:
-@name:
-@data:
-@ddt:
-
@@ -2221,8 +2862,8 @@ Sockets
-@whereto:
@tocopy:
+@whereto:
@Returns:
@@ -2306,8 +2947,8 @@ Sockets
-@whereto:
@Returns:
+@whereto:
@@ -2406,92 +3047,38 @@ Sockets
-@cfg:
-@name:
-@val:
-@Returns:
-
-
-
-
-
-
-@cfg:
-@options:
-@Returns:
-
-
-
-
-
-
-@cfg:
-@name:
-@val:
-@Returns:
-
-
-
-
-
-
-@cfg:
-@pa:
-@Returns:
-
-
-
-
-
-
-@name:
-@element_type:
-@dynamic_size:
-@dst:
-@Returns:
-
-
-
-
-
-
-@name:
-@element_type:
-@fixed_size:
-@dst:
-@Returns:
-
-
-
-
-
-
+@cfg:
@name:
+@val:
@Returns:
-@type:
-
+
-@name:
+@cfg:
+@options:
+@Returns:
-
+
-@type:
-@post:
+@cfg:
+@name:
+@val:
+@Returns:
-
+
-@type:
-@pre:
+@cfg:
+@pa:
+@Returns:
@@ -2837,108 +3424,6 @@ Sockets
@code:
@def:
-
-
-
-
-
-@name:
-@referenced_type:
-@dst:
-@Returns:
-
-
-
-
-
-
-@name:
-@selector:
-@dst:
-@Returns:
-@discriminant:
-
-
-
-
-
-
-@element_type:
-@dst:
-@Returns:
-
-
-
-
-
-
-@name:
-@dst:
-@Returns:
-
-
-
-
-
-
-@struct_type:
-@name:
-@field_type:
-@Returns:
-
-
-
-
-
-
-@struct_type:
-
-
-
-
-
-
-@vars:
-@data:
-@Returns:
-@p_type:
-
-
-
-
-
-
-@vars:
-@data:
-@p_type:
-
-
-
-
-
-
-@name:
-@selector:
-@dst:
-@Returns:
-
-
-
-
-
-
-@union_type:
-@name:
-@field_type:
-@Returns:
-
-
-
-
-
-
-@union_type:
-
@@ -3171,8 +3656,8 @@ Sockets
@head:
-@cursor:
@Returns:
+@cursor:
@@ -3266,8 +3751,8 @@ Sockets
-@dict:
@Returns:
+@dict:
@@ -3459,10 +3944,11 @@ Sockets
-@whereto:
-@elm_size:
+@Param1:
@free_func:
@Returns:
+@whereto:
+@elm_size:
@@ -3558,7 +4044,6 @@ Sockets
@no_error: no error
-@malloc_error: Well known error
@mismatch_error: Not found
@system_error: a syscall did fail
@network_error: error while sending/receiving data
@@ -3642,14 +4127,6 @@ Sockets
@msg:
-
-
-
-
-
-@timeOut:
-@Returns:
-
@@ -3661,72 +4138,6 @@ Sockets
@Varargs:
@Returns:
-
-
-
-
-
-@sock:
-@msgtype:
-@payload:
-@Returns:
-@sd:
-@msg:
-@freeDirective:
-
-
-
-
-
-
-@timeout:
-@msgt_want:
-@expeditor:
-@payload:
-@Returns:
-@id:
-@message:
-
-
-
-
-
-
-@name:
-@Returns:
-@dst:
-
-
-
-
-
-
-@name:
-@version:
-@Returns:
-@dst:
-
-
-
-
-
-
-@name:
-@payload:
-@Returns:
-@dst:
-
-
-
-
-
-
-@name:
-@version:
-@payload:
-@Returns:
-@dst:
-
@@ -3738,21 +4149,6 @@ Sockets
@Varargs:
@Returns:
-
-
-
-
-
-@Param1:
-@Param2:
-
-
-
-
-
-
-@Returns:
-
@@ -3815,8 +4211,8 @@ Sockets
-@dst:
@Returns:
+@dst:
@@ -3870,62 +4266,6 @@ Sockets
@sock:
@Returns:
-
-
-
-
-
-@host:
-@Param2:
-@dst:
-@Returns:
-@bufSize:
-@sock:
-
-
-
-
-
-
-@sd:
-@sock:
-@Returns:
-
-
-
-
-
-
-@sock:
-@Returns:
-
-
-
-
-
-
-@sock:
-@Returns:
-@sd:
-
-
-
-
-
-
-@sock:
-@Returns:
-
-
-
-
-
-
-@Param1:
-@dst:
-@Returns:
-@bufSize:
-
@@ -3940,23 +4280,22 @@ Sockets
@Returns:
-
-
-
-
-
-
-
-
-
-
-
-@type:
-
-
+
-@ud:
+@no_error:
+@mismatch_error:
+@system_error:
+@network_error:
+@timeout_error:
+@thread_error:
+@unknown_error:
+@remote_mismatch_error:
+@remote_system_error:
+@remote_network_error:
+@remote_timeout_error:
+@remote_thread_error:
+@remote_unknown_error: