| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the ipc code from the common project. The 'common' project pulls in
all of webkit, the v8 bindings, skia, googleurl, and a number of other projects
which makes it very difficult to deal with especially for external projects
wanting just to use some of Chromium's infrastructure. This puts the ipc code
into its top-level ipc/ directory with a dependency only on base. The common
project depends on the new ipc/ipc.gyp:ipc target so that all projects currently
pulling common in to get the IPC code still have it available. This mostly
follows agl's pre-gyp attempt to do this which was r13062.
Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to
use the IPC infrastructure. Rather than fixing all of these dependencies I have
made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules
section of DEPS so that checkdeps.py doesn't complain. Over time projects that
need IPC should depend on the IPC project themselves and dependencies on common
removed, although I don't think many projects that need IPC will be able to get
away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a
ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve
this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env
variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion
of ipc/ being an independent library. I think this should be examined in a
subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way
to create a dependency from ipc/ to chrome/common/chrome_counters. This is the
same approach that r13062 took.
http://codereview.chromium.org/155905
(Patch from James Robinson)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
This reverts commit r13062 which, unsurprisingly, broke the build.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
(No review URL: Rietvelt couldn't cope)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FileDescriptor API is clearly too hard to use. It's the only IPC
data type which is non-POD and serialising an invalid file descriptor
is fatal to Chrome on POSIX. The use of Maybe is possibly non-obvious
to non-functional programmers.
This patch merges Maybe and FileDescriptor so that serialising invalid
file descriptors is permitted and results in -1 at the other end.
(Serialising /closed/ a file descriptor is still fatal.) Also, it adds
a pointer in base/file_descriptor.h to instructions for its use with
IPC. Although it's generally bad practice to mention IPC in base, in
this case I cannot find another suitable location.
Review URL: http://codereview.chromium.org/39208
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11041 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
This patch adds the long planned support for sharing memory on POSIX
by transporting file descriptors. It largely builds on the shared
memory cleanup work by jrg.
We move FileDescriptor out of chrome/common/file_descriptor_posix.h
and into base/file_descriptor_posix.h. Since all that's left in the
chrome/common verion is the DescriptorSet, those files are renamed to
descriptor_set.[h|cc].
The SharedMemoryHandle on POSIX then becomes a typedef to a
FileDescriptor and thus can be serialised over IPC.
After that, it's mostly a case of cleaning up those snippets of code
which considered SharedMemoryHandles to be scaler values.
Review URL: http://codereview.chromium.org/21208
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9580 0039d316-1c4b-4281-b951-d872f2087c98
|
