| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a lot of redundant error checking and initialization code in all Pickle Read methods because of the void** iterator type. This change replaces the void* iterator with PickleIterator, which encapsulates the read pointer so that less error checking and initialization code is needed for reading.
PickleIterator has all the necessary data to do the actual reading. The advantage of having it provide Read methods (as opposed to leaving them solely in the Pickle interface) is that the callers do not need to pass around the const Pickle* once they have a PickleIterator.
Followup CLs will refactor the call sites to remove const Pickle* arguments where they are now unnecessary. Then the Pickle::Read* methods can be removed entirely.
The alternative approach would have been to change the Pickle::Read methods to non-const and remove the iterator parameter (making Read methods advance an internal read pointer). Unfortunately, the const Read with iterator design is entrenched throughout the chromium code, making this a much more complex change with the same performance outcome.
BUG=13108
Review URL: https://chromiumcodereview.appspot.com/9447084
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@125447 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes MessageWithTuple and MessageWithReply since it
is not easy to export a class that inherits from a template
specialization. The functionality of those classes are split
now between new classes, MessageSchema and SyncMessageSchema,
and being declared inline via macros.
The key point is that we want to avoid inlining the constructor
and Read functions for messages. That avoids code bloat since
those functions contain all of the parameter serialization and
deserialization code. Those are the functions that we really
want to have contained with component DLLs.
To export IPC messages from a DLL, it is necessary to #define
IPC_MESSAGE_EXPORT above message declarations. You can see this
in action here:
http://codereview.chromium.org/7687005/diff/41012/ppapi/proxy/ppapi_messages.h
Review URL: http://codereview.chromium.org/7768001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@98491 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/6581046
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@76417 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
That patch wasn't what caused the regression in the page cycler.
BUG=51411,52103
TEST=still compiles
Review URL: http://codereview.chromium.org/3106018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56390 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
cycler.
BUG=51411,52103
TEST=page cycler
Review URL: http://codereview.chromium.org/3170020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56272 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This forces all the ReadParam template junk to expand once in the *_messages.cc
file, instead of at every Read() call site. Without the compiler-specific
annotation, this builds and links in debug mode, but doesn't link in release
mode because the individual Read() methods generated were inlined into the
subclass Log() methods, causing disaster on the release builders, but not on
the trybots or locally.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/3160008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56081 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
collided with.
BUG=51411
TEST=none
TBR=mpcomplete
Review URL: http://codereview.chromium.org/3118009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55749 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r55735.
BUG=none
TEST=none
TBR=mirandac
Review URL: http://codereview.chromium.org/3152007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55738 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a continuation of r55259, where we convert the remaining IPC messages
to the new system. At this point, all the messages should be able to accept
forward declared classes/structs as parameters.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/3018045
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55735 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves MessageWithTuple::Read() back into the main ipc_message_utils.h
header from the private ipc_messsage_utils_impl.h header. In release mode, this
was causing link failures.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/3069034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55587 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CONTROL messages.
The slowest cc files in chrome include render_messages.h and other IPC message
definitions. Including one of these files will bring in half of chrome because
in the IPC system previously required full class definitions due to
implementation details.
The new system allows forward declarations and places the implementations of
functions that need the full class definitions (ctor/dtor()/Log() and
superclass ctor/Read() methods) into a separate xxx_messages.cc file using a
parallel set of macros to ipc_message_macros.h. This has the added benefit
of moving most of the template instantiation junk into a small number of
files.
Pros:
- Will speed up compiling by a lot once everything is forward declared.
- Already, intermediary .o/.a files are smaller.
Cons:
- Adds a 4th pass to the messages system, this time in a different header.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/2873090
TBR=erg@google.com
Review URL: http://codereview.chromium.org/3080040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55406 0039d316-1c4b-4281-b951-d872f2087c98
|
|
The slowest cc files in chrome include render_messages.h and other IPC message
definitions. Including one of these files will bring in half of chrome because
in the IPC system previously required full class definitions due to
implementation details.
The new system allows forward declarations and places the implementations of
functions that need the full class definitions (ctor/dtor()/Log() and
superclass ctor/Read() methods) into a separate xxx_messages.cc file using a
parallel set of macros to ipc_message_macros.h. This has the added benefit
of moving most of the template instantiation junk into a small number of
files.
Pros:
- Will speed up compiling by a lot once everything is forward declared.
- Already, intermediary .o/.a files are smaller.
Cons:
- Adds a 4th pass to the messages system, this time in a different header.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/2873090
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55259 0039d316-1c4b-4281-b951-d872f2087c98
|