[ https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874967#comment-15874967 ]
ASF GitHub Bot commented on THRIFT-3891: ---------------------------------------- Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1196 Once someone has a chance to approve the changes I can merge. > TNonblockingServer configured with more than one IO threads does not always > return from serve() upon stop() > ----------------------------------------------------------------------------------------------------------- > > Key: THRIFT-3891 > URL: https://issues.apache.org/jira/browse/THRIFT-3891 > Project: Thrift > Issue Type: Bug > Components: C++ - Library > Affects Versions: 0.9.3 > Reporter: Buğra Gedik > Assignee: James E. King, III > Priority: Minor > Attachments: patch.diff > > > Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is > race condition in which {{stop()}} does not properly unblock {{serve()}}. > The problem manifests itself when {{stop()}} is called (obviously from a > different thread) soon after {{serve()}}. > The core issue is that, {{event_base_loopbreak()}} is called within the > {{stop()}} sequence without checking whether the IO thread has actually > entered its event loop. The documentation of {{event_base_loopbreak()}} says > (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html) > {quote} > Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base) > act differently when no event loop is running: loopexit schedules the next > instance of the event loop to stop right after the next round of callbacks > are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only > stops a currently running loop, and has no effect if the event loop isn’t > running. > {quote} > Attached is a patch (against the released 0.9.3 version of the codebase). -- This message was sent by Atlassian JIRA (v6.3.15#6346)