diff options
author | pinkerton@google.com <pinkerton@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-08-09 16:06:58 +0000 |
---|---|---|
committer | pinkerton@google.com <pinkerton@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-08-09 16:06:58 +0000 |
commit | 071b4b94196fafbf3557771d41db81fa9a7d0ba7 (patch) | |
tree | 6c55110df8cdb9a592e6b79ce3a0bab833dad2bd /ipc/ipc_message_utils.h | |
parent | c9f28a7d16b71b17185b456e3b53e4e638d005d0 (diff) | |
download | chromium_src-071b4b94196fafbf3557771d41db81fa9a7d0ba7.zip chromium_src-071b4b94196fafbf3557771d41db81fa9a7d0ba7.tar.gz chromium_src-071b4b94196fafbf3557771d41db81fa9a7d0ba7.tar.bz2 |
Revert 55259 - FBTF: New IPC definitions, only applied to async ROUTED and 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
Diffstat (limited to 'ipc/ipc_message_utils.h')
-rw-r--r-- | ipc/ipc_message_utils.h | 60 |
1 files changed, 36 insertions, 24 deletions
diff --git a/ipc/ipc_message_utils.h b/ipc/ipc_message_utils.h index 1486a42..4667d4b 100644 --- a/ipc/ipc_message_utils.h +++ b/ipc/ipc_message_utils.h @@ -18,7 +18,7 @@ #include "base/string16.h" #include "base/string_number_conversions.h" #include "base/string_util.h" -#include "base/utf_string_conversions.h" +#include "base/time.h" #include "base/tuple.h" #include "base/utf_string_conversions.h" #include "base/values.h" @@ -67,13 +67,6 @@ enum IPCMessageStart { LastMsgIndex }; -class DictionaryValue; -class ListValue; - -namespace base { -class Time; -} - namespace IPC { //----------------------------------------------------------------------------- @@ -313,9 +306,19 @@ struct ParamTraits<wchar_t> { template <> struct ParamTraits<base::Time> { typedef base::Time param_type; - static void Write(Message* m, const param_type& p); - static bool Read(const Message* m, void** iter, param_type* r); - static void Log(const param_type& p, std::wstring* l); + static void Write(Message* m, const param_type& p) { + ParamTraits<int64>::Write(m, p.ToInternalValue()); + } + static bool Read(const Message* m, void** iter, param_type* r) { + int64 value; + if (!ParamTraits<int64>::Read(m, iter, &value)) + return false; + *r = base::Time::FromInternalValue(value); + return true; + } + static void Log(const param_type& p, std::wstring* l) { + ParamTraits<int64>::Log(p.ToInternalValue(), l); + } }; #if defined(OS_WIN) @@ -362,9 +365,6 @@ struct ParamTraits<MSG> { return result; } - static void Log(const param_type& p, std::wstring* l) { - l->append(L"<MSG>"); - } }; #endif // defined(OS_WIN) @@ -1026,14 +1026,20 @@ template <class ParamType> class MessageWithTuple : public Message { public: typedef ParamType Param; - typedef typename TupleTypes<ParamType>::ParamTuple RefParam; + typedef typename ParamType::ParamTuple RefParam; - // The constructor and the Read() method's templated implementations are in - // ipc_message_utils_impl.h. The subclass constructor and Log() methods call - // the templated versions of these and make sure there are instantiations in - // those translation units. - MessageWithTuple(int32 routing_id, uint32 type, const RefParam& p); - static bool Read(const Message* msg, Param* p); + MessageWithTuple(int32 routing_id, uint32 type, const RefParam& p) + : Message(routing_id, type, PRIORITY_NORMAL) { + WriteParam(this, p); + } + + static bool Read(const Message* msg, Param* p) { + void* iter = NULL; + if (ReadParam(msg, &iter, p)) + return true; + NOTREACHED() << "Error deserializing message " << msg->type(); + return false; + } // Generic dispatcher. Should cover most cases. template<class T, class Method> @@ -1105,6 +1111,12 @@ class MessageWithTuple : public Message { return false; } + static void Log(const Message* msg, std::wstring* l) { + Param p; + if (Read(msg, &p)) + LogParam(p, l); + } + // Functions used to do manual unpacking. Only used by the automation code, // these should go away once that code uses SyncChannel. template<typename TA, typename TB> @@ -1177,7 +1189,7 @@ template <class SendParamType, class ReplyParamType> class MessageWithReply : public SyncMessage { public: typedef SendParamType SendParam; - typedef typename TupleTypes<SendParam>::ParamTuple RefSendParam; + typedef typename SendParam::ParamTuple RefSendParam; typedef ReplyParamType ReplyParam; MessageWithReply(int32 routing_id, uint32 type, @@ -1204,7 +1216,7 @@ class MessageWithReply : public SyncMessage { } else { // This is an outgoing reply. Now that we have the output parameters, we // can finally log the message. - typename TupleTypes<ReplyParam>::ValueTuple p; + typename ReplyParam::ValueTuple p; void* iter = SyncMessage::GetDataIterator(msg); if (ReadParam(msg, &iter, &p)) LogParam(p, l); @@ -1218,7 +1230,7 @@ class MessageWithReply : public SyncMessage { Message* reply = GenerateReply(msg); bool error; if (ReadParam(msg, &iter, &send_params)) { - typename TupleTypes<ReplyParam>::ValueTuple reply_params; + typename ReplyParam::ValueTuple reply_params; DispatchToMethod(obj, func, send_params, &reply_params); WriteParam(reply, reply_params); error = false; |