workaround for mac kernel bug

ipc/ipc_channel.h

Index: ipc/ipc_channel.h
diff --git a/ipc/ipc_channel.h b/ipc/ipc_channel.h
index f65a62b9cc9ee4fda212d66b513f76c60737ba9c..f9e3532672e861f6f594cb8b404765fd2d2739cd 100644
--- a/ipc/ipc_channel.h
+++ b/ipc/ipc_channel.h
@@ -80,10 +80,14 @@ class IPC_EXPORT Channel : public Sender {
   // just the process id (pid).  The message has a special routing_id
   // (MSG_ROUTING_NONE) and type (HELLO_MESSAGE_TYPE).
   enum {
-    HELLO_MESSAGE_TYPE = kuint16max  // Maximum value of message type (uint16),
+    HELLO_MESSAGE_TYPE = kuint16max,  // Maximum value of message type (uint16),
                                      // to avoid conflicting with normal
                                      // message types, which are enumeration
                                      // constants starting from 0.
+
+    // The CLOSE_FD_MESSAGE_TYPE is used internall in the IPC class to
+    // work around a bug in sendmsg() on Mac.
+    CLOSE_FD_MESSAGE_TYPE = kuint16max - 1

[Scott Hess - ex-Googler, 2013/10/09 20:18:33]

internall -> internally.

I think the comment is saying why this is here, but not what it does.  It seems
like if there's going to be a second one, maybe the comments should be
refactored to indicate the entire enum is about internal messages (with high
numbers to not conflict), and then have per-message comments with the
definitions.

Could you use HELLO_MESSAGE_TYPE - 1?  Presumably nobody else will define
another one, but you never know...

[hubbe, 2013/10/09 21:34:12]

Done.

   };
 
   // The maximum message size in bytes. Attempting to receive a message of this