[ https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837187#comment-15837187 ]
ASF GitHub Bot commented on THRIFT-3891: ---------------------------------------- Github user jeking3 commented on a diff in the pull request: https://github.com/apache/thrift/pull/1080#discussion_r97708735 --- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp --- @@ -1524,7 +1532,7 @@ void TNonblockingIOThread::breakLoop(bool error) { } // sets a flag so that the loop exits on the next event - event_base_loopbreak(eventBase_); + event_base_loopexit(eventBase_, 0); --- End diff -- I am curious to understand why this was changed. event_base_loopexit will cause the lop to continue processing until drained. This function is called breakLoop and I assume that means stop as soon as possible, which is what it was doing. > 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 > 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.4#6332)