Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
From 25a03ad050ecb05236e7069771e5047d15245d18 Mon Sep 17 00:00:00 2001
From: Adam Simpkins <simpkins@fb.com>
Date: Thu, 10 Jun 2010 01:16:08 +0000
Subject: [PATCH 02/56] thrift: define a TProcessor helper class to implement
process()
Summary:
All of the generated TProcessor implementations contain identical
process() methods, which is unnecessary code duplication. This defines
two new helper classes to provide an implementation of process(), so
that the generated processors can just use this instead of always
re-generating their own versions.
The new TDispatchProcessor classes do behave slightly differently from the old
classes:
- For templated processors, process() now detects if we're using the templated
protocol type or not. Previously this detection was being done separately in
each of the generated process_<method>() functions. This change also helps
reduce the amount of generated code.
However, this change does mean that processMap_ now has to contain
pointers to both the generic and specialized versions of each of the
process_<method>() functions. When templates are enabled, processMap_ is now
a map of string to a struct containing two method pointers, instead of just a
map from string to a single function pointer.
- If an invalid message type is received (i.e., something other than T_CALL or
T_ONEWAY), the new TDispatchProcessor classes close the connection. The old
generated processors would assume they were still being sent a valid
T_STRUCT, and try to skip it and read more messages after it. If the message
type is unknown, it seems better to close the connection rather than assume
it is still a valid T_STRUCT.
Test Plan:
Tested building [several internal FB projects] and various combinations of
template+async code generation.
DiffCamp Revision: 120254
Reviewed By: dreiss
Commenters: edhall
CC: dreiss, kholst, simpkins, edhall, thrift-team@lists
Revert Plan:
OK