thrift: define a TProcessor helper class to implement ------------------------------------------------------
Key: THRIFT-1443 URL: https://issues.apache.org/jira/browse/THRIFT-1443 Project: Thrift Issue Type: Improvement Components: C++ - Library Reporter: Dave Watson Priority: Minor Attachments: 0002-thrift-define-a-TProcessor-helper-class-to-implement.patch >From 25a03ad050ecb05236e7069771e5047d15245d18 Mon Sep 17 00:00:00 2001 From: Adam Simpkins <simpk...@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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira