thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Watson (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (THRIFT-1443) thrift: define a TProcessor helper class to implement
Date Thu, 01 Dec 2011 23:44:40 GMT
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 <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



--
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

        

Mime
View raw message