You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/02/18 20:17:44 UTC

[jira] [Commented] (THRIFT-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()

    [ https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873324#comment-15873324 ] 

ASF GitHub Bot commented on THRIFT-3891:
----------------------------------------

GitHub user jeking3 opened a pull request:

    https://github.com/apache/thrift/pull/1196

    THRIFT-3891 TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()

    I took the comments from @nsuke and applied them to the PR.  I was able to reasonably eliminate the boolean you mentioned however I could not go back to loopbreak.  I see no reasonable way to synchronize here.  The run() thread will eventually need to release a mutex and THEN call the event loop.  There's no way inside breakLoop() to know if it is actually IN the event loop.  Given this, the exit variant is the only safe method to break the loop.
    
    The obsoletes PR #1080.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/jeking3/thrift THRIFT-3891

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/thrift/pull/1196.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1196
    
----
commit 38d3c87aa11f1f4232cb97b01200c01fc578cd9d
Author: Buğra Gedik <bg...@gmail.com>
Date:   2016-09-04T08:18:15Z

    THRIFT-3891 TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()

----


> 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.15#6346)