[ 
https://issues.apache.org/jira/browse/THRIFT-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Watson updated THRIFT-1290:
--------------------------------

    Attachment: 
0017-thrift-TNonblockingServer-clean-up-state-in-the-dest.patch-2

svn up'd, resolved conflict

>  thrift: TNonblockingServer: clean up state in the

> ---------------------------------------------------
>
>                 Key: THRIFT-1290
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1290
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C++ - Library
>            Reporter: Dave Watson
>            Priority: Minor
>         Attachments: 
> 0017-thrift-TNonblockingServer-clean-up-state-in-the-dest.patch, 
> 0017-thrift-TNonblockingServer-clean-up-state-in-the-dest.patch-2
>
>
> From cd9c1a10cb4df058fbdbed1b98a21a7a7470a28c Mon Sep 17 00:00:00 2001
> From: Adam Simpkins <simpk...@fb.com>
> Date: Tue, 6 Apr 2010 20:43:23 +0000
> Subject: [PATCH 17/33] thrift: TNonblockingServer: clean up state in the
>  destructor
> Summary:
> Implement the TNonblockingServer destructor, so that it closes the
> listen socket, destroys the event_base, and deletes any TConnections
> left in the connectionStack_.  However, TNonblockingServer doesn't keep
> track of active TConnection objects, so those objects are still leaked.
> As part of this, I also changed the code to use event_init() rather than
> event_base_new().  This way we won't set the global event_base inside
> libevent, and we can be sure that no one else will be using it after the
> TNonblockingServer is destroyed.
> I grepped through all of [fb code base] to check for any other direct uses of
> event_set(), and didn't see any places that weren't also using
> event_base_set().  Therefore it seems like it should be safe to stop
> initializing the global event_base pointer.
> Test Plan:
> Tested with the test code in [a fb unittest], which creates, stops, and then
> deletes several TNonblockingServers.  Ran it under valgrind, and now it
> only complains about any active connections being leaked.
> Revert Plan:
> OK
> ---
>  lib/cpp/src/server/TNonblockingServer.cpp |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to