diff options
author | viettrungluu@chromium.org <viettrungluu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-11-07 17:49:50 +0000 |
---|---|---|
committer | viettrungluu@chromium.org <viettrungluu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-11-07 17:49:50 +0000 |
commit | ccf8453db576012646427004578a156a8830c4bf (patch) | |
tree | 3b8950f0029c1c3f1d3bcf10993d46660115dc9a /base/compiler_specific.h | |
parent | 2ccb47aa7dd2d32a488743a01dcaa1983cc8ae4c (diff) | |
download | chromium_src-ccf8453db576012646427004578a156a8830c4bf.zip chromium_src-ccf8453db576012646427004578a156a8830c4bf.tar.gz chromium_src-ccf8453db576012646427004578a156a8830c4bf.tar.bz2 |
Mojo: First stab at making MessagePipes work across OS pipes.
Given a running RawChannel, one can set up MessagePipes that have one endpoint
available locally (in the usual way) and the other endpoint proxied to the other
side of the OS-level "pipe" (which presumably has a symmetrical setup -- i.e.,
another RawChannel, etc.).
Currently, this has only been tested in-process, but apart from possible
synchronization/bootstrapping issues there's no reason it shouldn't work across
processes. (Whatever launches the process will have to begin the bootstrapping
by getting an OS pipe between processes and making sure things are appropriately
synchronized.)
Still to do:
- Properly handle errors (e.g., due to the pipe/process dying).
- Figure out how to start processes and bootstrap in that situation (and test
this).
R=darin@chromium.org, darin
Review URL: https://codereview.chromium.org/60103005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233638 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base/compiler_specific.h')
-rw-r--r-- | base/compiler_specific.h | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/base/compiler_specific.h b/base/compiler_specific.h index 07b680b..409a613 100644 --- a/base/compiler_specific.h +++ b/base/compiler_specific.h @@ -68,6 +68,28 @@ #endif // COMPILER_MSVC +// The C++ standard requires that static const members have an out-of-class +// definition (in a single compilation unit), but MSVC chokes on this (when +// language extensions, which are required, are enabled). (You're only likely to +// notice the need for a definition if you take the address of the member or, +// more commonly, pass it to a function that takes it as a reference argument -- +// probably an STL function.) This macro makes MSVC do the right thing. See +// http://msdn.microsoft.com/en-us/library/34h23df8(v=vs.100).aspx for more +// information. Use like: +// +// In .h file: +// struct Foo { +// static const int kBar = 5; +// }; +// +// In .cc file: +// STATIC_CONST_MEMBER_DEFINITION const int Foo::kBar; +#if defined(COMPILER_MSVC) +#define STATIC_CONST_MEMBER_DEFINITION __declspec(selectany) +#else +#define STATIC_CONST_MEMBER_DEFINITION +#endif + // Annotate a variable indicating it's ok if the variable is not used. // (Typically used to silence a compiler warning when the assignment // is important for some other reason.) |