4 files changed, 24 insertions, 25 deletions
diff --git a/doc/zmq_getsockopt.txt b/doc/zmq_getsockopt.txt
index 4aef71c..3225a18 100644
--- a/doc/zmq_getsockopt.txt
+++ b/doc/zmq_getsockopt.txt
@@ -10,7 +10,7 @@ zmq_getsockopt - get 0MQ socket options
 
 SYNOPSIS
 --------
-*int zmq_getsockopt (void '*socket', int 'option_name', void '*option_value', size_t 'option_len');*
+*int zmq_getsockopt (void '*socket', int 'option_name', void '*option_value', size_t '*option_len');*
 
 
 DESCRIPTION
@@ -19,7 +19,9 @@ The _zmq_getsockopt()_ function shall retrieve the value for the option
 specified by the 'option_name' argument for the 0MQ socket pointed to by the
 'socket' argument, and store it in the buffer pointed to by the 'option_value'
 argument. The 'option_len' argument is the size in bytes of the buffer pointed
-to by 'option_value'.
+to by 'option_value'; upon successful completion _zmq_getsockopt()_ shall
+modify the 'option_value' argument to indicate the actual size of the option
+value stored in the buffer.
 
 The following options can be retrieved with the _zmq_getsockopt()_ function:
 
diff --git a/doc/zmq_recv.txt b/doc/zmq_recv.txt
index 50be810..42df99a 100644
--- a/doc/zmq_recv.txt
+++ b/doc/zmq_recv.txt
@@ -31,10 +31,12 @@ to EAGAIN.
 
 Multi-part messages
 ~~~~~~~~~~~~~~~~~~~
-A 0MQ message is composed of 1 to N message parts; each message part is an
-independent 'zmq_msg_t' in its own right. The total number of message parts is
-unlimited. Consequently, wherever this documentation uses the term _message_ it
-may be substituted for _message part_.
+A 0MQ message is composed of 1 or more message parts; each message part is an
+independent 'zmq_msg_t' in its own right. 0MQ ensures atomic delivery of
+messages; peers shall receive either all _message parts_ of a message or none
+at all.
+
+The total number of message parts is unlimited.
 
 An application wishing to determine if a message is composed of multiple parts
 does so by retrieving the value of the _ZMQ_RCVMORE_ socket option on the
@@ -43,9 +45,6 @@ follow, or if the message is not composed of multiple parts, _ZMQ_RCVMORE_
 shall report a value of zero. Otherwise, _ZMQ_RCVMORE_ shall report a value of
 1, indicating that more message parts are to follow.
 
-0MQ shall ensure the atomicity of a multi-part message; peers shall receive
-either all _message parts_ of a multi-part message or none at all. 
-
 
 RETURN VALUE
 ------------
@@ -84,6 +83,7 @@ assert (rc == 0);
 .Receiving a multi-part message
 ----
 int64_t more;
+int64_t more_size = sizeof more;
 do {
     /* Create an empty 0MQ message to hold the message part */
     zmq_msg_t part;
@@ -93,7 +93,7 @@ do {
     rc = zmq_recv (socket, &part, 0);
     assert (rc == 0);
     /* Determine if more message parts are to follow */
-    rc = zmq_getsockopt (socket, ZMQ_RCVMORE, &more, sizeof more);
+    rc = zmq_getsockopt (socket, ZMQ_RCVMORE, &more, &more_size);
     assert (rc == 0);
 } while (more);
 ----
diff --git a/doc/zmq_send.txt b/doc/zmq_send.txt
index e4439f5..300f812 100644
--- a/doc/zmq_send.txt
+++ b/doc/zmq_send.txt
@@ -36,10 +36,12 @@ responsibility for the message.
 
 Multi-part messages
 ~~~~~~~~~~~~~~~~~~~
-A 0MQ message is composed of 1 to N message parts; each message part is an
-independent 'zmq_msg_t' in its own right. The total number of message parts is
-unlimited. Consequently, wherever this documentation uses the term _message_ it
-may be substituted for _message part_.
+A 0MQ message is composed of 1 or more message parts; each message part is an
+independent 'zmq_msg_t' in its own right. 0MQ ensures atomic delivery of
+messages; peers shall receive either all _message parts_ of a message or none
+at all.
+
+The total number of message parts is unlimited.
 
 An application wishing to send a multi-part message does so by specifying the
 'ZMQ_SNDMORE' flag to _zmq_send()_. The presence of this flag indicates to 0MQ
@@ -48,9 +50,6 @@ are to follow. When the application wishes to send the final message part it
 does so by calling _zmq_send()_ without the 'ZMQ_SNDMORE' flag; this indicates
 that no more message parts are to follow.
 
-0MQ shall ensure the atomicity of a multi-part message; peers shall receive
-either all _message parts_ of a multi-part message or none at all.
-
 
 RETURN VALUE
 ------------
diff --git a/doc/zmq_socket.txt b/doc/zmq_socket.txt
index ebae5e1..119ac31 100644
--- a/doc/zmq_socket.txt
+++ b/doc/zmq_socket.txt
@@ -70,10 +70,9 @@ for this socket type.
 Pipeline pattern
 ~~~~~~~~~~~~~~~~
 The pipeline pattern is used for distributing data to _nodes_ arranged in
-a pipeline. Data always flows *down* the pipeline, and each stage of the
-pipeline is connected to at least one _node_. When a pipeline stage is
-connected to multiple _nodes_ data is processed by all connected _nodes_ in
-parallel.
+a pipeline. Data always flows down the pipeline, and each stage of the pipeline
+is connected to at least one _node_. When a pipeline stage is connected to
+multiple _nodes_ data is load-balanced among all connected _nodes_.
 
 Socket type:: 'ZMQ_DOWNSTREAM'
 Compatible peer sockets:: 'ZMQ_UPSTREAM'
@@ -94,8 +93,8 @@ for this socket type.
 
 Exclusive pair pattern
 ~~~~~~~~~~~~~~~~~~~~~~
-The exclusive pair pattern is used for communicating exclusively between two
-peers.
+The exclusive pair is an advanced pattern used for communicating exclusively
+between two peers.
 
 Socket type:: 'ZMQ_PAIR'
 Compatible peer sockets:: 'ZMQ_PAIR'
@@ -105,8 +104,7 @@ time.  No message routing or filtering is performed on messages sent over a
 'ZMQ_PAIR' socket.
 
 NOTE: 'ZMQ_PAIR' sockets are experimental, and are currently missing several
-features such as auto-reconnection. Developers should consider other patterns
-in preference to the exclusive pair pattern.
+features such as auto-reconnection.
 
 
 RETURN VALUE