Initial in-process implementation of some Mojo primitives.

mojo/system/limits.h

Index: mojo/system/limits.h
diff --git a/mojo/system/limits.h b/mojo/system/limits.h
new file mode 100644
index 0000000000000000000000000000000000000000..e91bcb7f6a787acaf6c88394ddd891caab189bc4
--- /dev/null
+++ b/mojo/system/limits.h
@@ -0,0 +1,25 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef MOJO_SYSTEM_LIMITS_H_
+#define MOJO_SYSTEM_LIMITS_H_
+
+namespace mojo {
+namespace system {
+
+// Maximum of open (Mojo) handles.
+// TODO(vtl): This doesn't count "live" handles, some of which may live in
+// messages.
+const size_t kMaxHandleTableSize = 1000000;
+
+const size_t kMaxWaitManyNumHandles = 256;

[darin (slow to review), 2013/09/25 06:06:07]

In practice, I think we will quickly exceed this limit. We exceeded
WaitForMultipleObjects' limit of 64 very easily. It led us to build a very
complicated coping mechanism, relying on Win32 worker pools, etc. until we
finally switched over to IO completion ports, which don't have this low of a
limit.

Plus, given that we imagine creating a lot of message pipes, it seems like the
limit here should be much higher and have more to do with address space
limitations.

[viettrungluu, 2013/09/25 18:22:16]

Okay. (256 was a low-ish number that I chose arbitrarily. We can adjust "low"
upwards some.)

+
+const size_t kMaxMessageNumBytes = 4 * 1024 * 1024;
+
+const size_t kMaxMessageNumHandles = 256;

[darin (slow to review), 2013/09/25 06:06:07]

i'd be tempted to also allow this to be larger unless it somehow hurts to have
it be larger.

[viettrungluu, 2013/09/25 18:22:16]

Ditto.

What do you think of 1024 as the limit for these?

(They aren't without cost, which is why I don't want to give the impression
that, say, sending 100000 handles is a good idea.)

+
+}  // namespace system
+}  // namespace mojo
+
+#endif  // MOJO_SYSTEM_LIMITS_H_