[
https://issues.apache.org/jira/browse/THRIFT-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617321#comment-14617321
]
Ben Craig commented on THRIFT-3225:
-----------------------------------
-1
close() doesn't need to be / shouldn't be thread safe, and this patch doesn't
solve the race condition. The 'other' thread should be calling interrupt() on
the pipe, then let the main server thread close the pipe when it is complete.
Closing a transport that is currently in use is an anti-pattern. You wouldn't
delete memory while it is in use. You shouldn't close a transport while it is
in use. This 'mostly' works for sockets, but only 'mostly'.
> Fix TPipeServer unpredictable behavior on close
> -----------------------------------------------
>
> Key: THRIFT-3225
> URL: https://issues.apache.org/jira/browse/THRIFT-3225
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Environment: Windows
> Reporter: Paweł Janicki
> Assignee: Paweł Janicki
> Priority: Critical
> Labels: patch
> Attachments:
> 0001-THRIFT-3225.-cpp-Fix-TPipeServer-unpredictable-behav.patch
>
>
> If TPipeServer::close() is invoked from other thread than the thread that is
> blocked on TPipeServer::serve() the handle may be closed by each thread while
> should be closed only once.
> I propose to solve the issue by synchronizing access to close() method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
