README.md in celluloid-0.5.0 vs README.md in celluloid-0.6.0

@@ -355,17 +355,47 @@
 	  def send_signal(value)
 	    signal :ponycopter, value
 	  end
 	end
 
-The wait_for_signal method in turn calls a method called "wait". Wait suspends
+The #wait_for_signal method in turn calls a method called "wait". Wait suspends
 the running method until another method of the same object calls the "signal"
 method with the same label.
 
-The send_signal method of this class does just that, signaling "ponycopter"
+The #send_signal method of this class does just that, signaling "ponycopter"
 with the given value. This value is returned from the original wait call.
 
+Protocol Interaction
+--------------------
+
+The asynchronous message protocol Celluloid uses can be used directly to add
+new behavior to actors.
+
+To send a raw asynchronous message to an actor, use:
+
+    actor.mailbox << MyMessage.new
+
+Methods can wait on incoming MyMessage objects using the #receive method:
+
+    class MyActor
+      def initialize
+        wait_for_my_messages!
+      end
+
+      def wait_for_my_messages
+        loop do
+          message = receive { |msg| msg.is_a? MyMessage }
+		  puts "Got a MyMessage: #{message.inspect}"
+        end
+      end
+    end
+
+The #receive method takes a block, and yields any incoming messages which are
+received by the current actor to the block, waiting for the block to return
+true. Calls to #receive sleep until a message is received which makes the
+block return true, at which point the matching message is returned.
+
 Handling I/O with Celluloid::IO
 -------------------------------
 
 Celluloid provides a separate class of actors which run alongside I/O
 operations. These actors are slower and more heavyweight and should only be
@@ -453,9 +483,13 @@
    of how it implements actors. While it's possible for certain uses of Fibers
    to cooperatively work alongside how Celluloid behaves, in most cases you'll
    be writing a check you can't afford. So please ask yourself: why are you
    using Fibers, and why can't it be solved by a block? If you've got a really
    good reason and you're feeling lucky, knock yourself out.
+
+5. If you need to mock the behaviour of an Actor, you should mock its subject
+   rather than the proxy itself (#actor_subject). This ensures that any time
+   the subject calls methods on self, they will also be appropriately mocked.
 
 On Thread Safety in Ruby
 ------------------------
 
 Ruby actually has a pretty good story when it comes to thread safety. The best