[Spread-cvs] commit: r327 - in trunk: docs include
jgreen at spread.org
jgreen at spread.org
Thu Mar 2 13:27:37 EST 2006
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 );
More information about the Spread-cvs
mailing list