[mojo-edk] Expose notification source to MojoWatch callbacks

mojo/public/cpp/bindings/binding.h

Index: mojo/public/cpp/bindings/binding.h
diff --git a/mojo/public/cpp/bindings/binding.h b/mojo/public/cpp/bindings/binding.h
index 68dd32239c41c3d1682c5ca12303f95bf7f16089..51f569633e551b65d92e3fee0df188def60ecc62 100644
--- a/mojo/public/cpp/bindings/binding.h
+++ b/mojo/public/cpp/bindings/binding.h
@@ -208,6 +208,16 @@ class Binding {
     return internal_state_.associated_group();
   }
 
+  // Allows synchronous dispatch for this Binding. When sync dispatch is

[yzshen1, 2016/03/16 15:38:18]

This comment also needs to mention bindings living on the IO thread and the
client is out of process. And likely that is the only case that we would like to
use this feature. Is that correct?

I feel that this is something related to our implementation details and hard to
explain clearly as a public API. I wonder whether we can have a flag passed into
the watcher API's callback, indicating whether the signal state change is
directly resulted from a Mojo system API call (as opposed to receiving a message
from another process). If it is not, then we should be safe to do sync
dispatching, right?

If the approach above is not possible, maybe we should consider a different
method name. The current name sounds to me that it is related to sync method
call.

WDYT? I am happy to chat about this in person if that is more convenient.

+  // allowed, a client on the same thread as this Binding will synchronously
+  // enter the bound implementation when writing messages to its pipe.
+  //
+  // Note that this also allows synchronous dispatch for any endpoints
+  // which are associated with this one and which live on the same thread.
+  void SetAllowSyncDispatch(bool allowed) {
+    internal_state_.SetAllowSyncDispatch(allowed);
+  }
+
   // Exposed for testing, should not generally be used.
   void EnableTestingMode() { internal_state_.EnableTestingMode(); }