commit: r327 - in trunk: docs include

Author: jgreen
Date: 2006-03-02 13:27:37 -0500 (Thu, 02 Mar 2006)
New Revision: 327

Modified:
   trunk/docs/Flush_or_SpreadAPI.txt
   trunk/docs/MultithreadedClients.txt
   trunk/docs/SP_receive.3
   trunk/docs/Short_Buffer_Handling.txt
   trunk/include/sp_func.h
Log:
various spelling mistakes corrected


Modified: trunk/docs/Flush_or_SpreadAPI.txt
===================================================================
--- trunk/docs/Flush_or_SpreadAPI.txt	2006-03-02 18:25:35 UTC (rev 326)
+++ trunk/docs/Flush_or_SpreadAPI.txt	2006-03-02 18:27:37 UTC (rev 327)
@@ -3,7 +3,7 @@
 
 The Flush Spread API is an extension to the Spread Wide Area Group
 Communication System. Flush Spread and Core Spread are extremely
-similiar group communication systems (GCSs), in the services that they
+similar group communication systems (GCSs), in the services that they
 provide, and in their general interface. Therefore, reading Spread's
 documentation before reading Flush Spread's documentation is highly
 recommended to get a general grasp of group communication and to fill
@@ -29,7 +29,7 @@
 presented to the client without its permission.
 
 In a VS system, when an underlying membership change occurs (another
-member joins/leaves/disconnects, network parititions or merges) the
+member joins/leaves/disconnects, network paritions or merges) the
 GCS generates a flush request message indicating that the current view
 is out-of-date and requesting permission to install a new view. The
 client is still allowed to send messages at this point, and they may
@@ -81,7 +81,7 @@
 Under Spread, a client can call group specific calls such as join,
 leave, and *cast (multicast and its variants) pretty much whenever
 they want regardless of their membership in that group. Also, under
-Spread the guarantees of multicast messages span differerent
+Spread the guarantees of multicast messages span different
 groups. For example, if a sender sends two FIFO messages to two
 different groups and a receiver receives both messages, they will
 always receive the first and then the second FIFO message.

Modified: trunk/docs/MultithreadedClients.txt
===================================================================
--- trunk/docs/MultithreadedClients.txt	2006-03-02 18:25:35 UTC (rev 326)
+++ trunk/docs/MultithreadedClients.txt	2006-03-02 18:27:37 UTC (rev 327)
@@ -94,7 +94,7 @@
 speaking, unsafe, because a parent thread may have a Mutex lock on the
 mailbox because it is reading from the socket and once the locks in
 the child are reset, the child process could also attempt a read --
-resulting in garbage in both processe.  However -- We document and
+resulting in garbage in both process.  However -- We document and
 require that spread mailboxes cannot be read from different processes
 at the same time, so the application is responsible for not using them
 this way.

Modified: trunk/docs/SP_receive.3
===================================================================
--- trunk/docs/SP_receive.3	2006-03-02 18:25:35 UTC (rev 326)
+++ trunk/docs/SP_receive.3	2006-03-02 18:27:37 UTC (rev 327)
@@ -128,7 +128,7 @@
 
 The 
 .I sender
-char array will be set to the name of the group for which the membership change is occuring.
+char array will be set to the name of the group for which the membership change is occurring.
 
 The 
 .I max_groups
@@ -213,7 +213,7 @@
 the layout of the membership message can change between versions, the
 best way to process them is to use the functions we provide that translate the
 message body into well-defined structures of membership information. The parsing
-functions have two varients, one for regular message bodies that are one contiguous
+functions have two variants, one for regular message bodies that are one contiguous
 array of bytes, and one for message bodies set up as scatters.
 
 .RS

Modified: trunk/docs/Short_Buffer_Handling.txt
===================================================================
--- trunk/docs/Short_Buffer_Handling.txt	2006-03-02 18:25:35 UTC (rev 326)
+++ trunk/docs/Short_Buffer_Handling.txt	2006-03-02 18:27:37 UTC (rev 327)
@@ -1,10 +1,10 @@
 Short Buffer Handling
 
-The traditional behaivor of networking APIs when a user provided
+The traditional behavior of networking APIs when a user provided
 buffer is insufficient is to provide as much data as possible and
 truncate the rest. Sometimes the user receives a notice that some data
 was truncated and sometimes no notification is given. Thus it is the
-user's responsiblity to detect when datagrams are too short and
+user's responsibility to detect when datagrams are too short and
 recover in some way (such as re-requesting data).
 
 The difficulty with using this approach in Spread is that when the

Modified: trunk/include/sp_func.h
===================================================================
--- trunk/include/sp_func.h	2006-03-02 18:25:35 UTC (rev 326)
+++ trunk/include/sp_func.h	2006-03-02 18:27:37 UTC (rev 327)
@@ -104,7 +104,7 @@
 int     SP_get_vs_set_members( const char *memb_mess, 
                                const vs_set_info *vs_set, 
                                char member_names[][MAX_GROUP_NAME],
-                               int member_names_cnt);
+                               int member_names_count);
 
 int     SP_scat_get_memb_info( const scatter *memb_mess_scat, 
                                const service service_type,
@@ -116,7 +116,7 @@
 int     SP_scat_get_vs_set_members( const scatter *memb_mess_scat, 
                                     const vs_set_info *vs_set, 
                                     char member_names[][MAX_GROUP_NAME],
-                                    int member_names_cnt);
+                                    int member_names_count);
 
 int	SP_poll( mailbox mbox );